Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)
--
Hendy Irawan
http://www.gauldong.net
http://dev.gauldong.net
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)
I for one would love them since they are very nice and concise for
functions that take optional parameters and have a lot of them (such as
generic search functions). It would save on the creation of a temporary
array, and then having pass that to the function. But then, I also think
this has been to the list before, and we don't currently have named
parameters, so I'm guessing it got shot down already :)
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)I for one would love them since they are very nice and concise for
functions that take optional parameters and have a lot of them (such as
generic search functions). It would save on the creation of a temporary
array, and then having pass that to the function. But then, I also think
this has been to the list before, and we don't currently have named
parameters, so I'm guessing it got shot down already :)
Yeah, I think so... but I did a search on the archives and found
nothing (at least, I found nothing on the first N results... maybe the
full text indexer needed some tweaking)
Anyways, what PHP alternatives to PHP are already available out there?
I think it's nice to have a "risk your life" PHP version that merges
all available patches that never got into the official PHP. People
building the "RYL" PHP will have to specify something like:
./configure --enable-named-parameters --enable-attributes
to enable these features (or maybe --enable-all-experimental for the
most adventurous). Giving no optional features would build an exact
PHP as the official version.
Does something like this already exist?
--
Hendy Irawan
http://www.gauldong.net
http://dev.gauldong.net
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)I for one would love them since they are very nice and concise for
functions that take optional parameters and have a lot of them (such as
generic search functions). It would save on the creation of a temporary
array, and then having pass that to the function. But then, I also think
this has been to the list before, and we don't currently have named
parameters, so I'm guessing it got shot down already :)
Yeah, I think so... but I did a search on the archives and found
nothing (at least, I found nothing on the first N results... maybe the
full text indexer needed some tweaking)Anyways, what PHP alternatives to PHP are already available out there?
I think it's nice to have a "risk your life" PHP version that merges
all available patches that never got into the official PHP. People
building the "RYL" PHP will have to specify something like:./configure --enable-named-parameters --enable-attributes
to enable these features (or maybe --enable-all-experimental for the
most adventurous). Giving no optional features would build an exact
PHP as the official version.Does something like this already exist?
Not that I know of. I think such a concept would be interesting though,
not as a RYL package, but as a power feature package-- especially if it
had a mandate to maintain 100% compatibility with normal PHP. Then power
users could use all of the existing scripts made for PHP and have all
the power features of Power-PHP (not that it could be called Power-PHP
without the blessing of Zend :)
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
the power features of Power-PHP (not that it could be called Power-PHP
without the blessing of Zend :)
The PHP Group, not Zend.
--Wez.
the power features of Power-PHP (not that it could be called Power-PHP
without the blessing of Zend :)The PHP Group, not Zend.
My bad and my apologies to the PHP Group.
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Not that I know of. I think such a concept would be interesting though,
not as a RYL package, but as a power feature package-- especially if it
had a mandate to maintain 100% compatibility with normal PHP. Then power
users could use all of the existing scripts made for PHP and have all
the power features of Power-PHP (not that it could be called Power-PHP
without the blessing of Zend :)
Yeah... I'd love something like that (if it exists ;-). Name doesn't
really matter, but if it has "power" in it, it can even be dangerous
to the official PHP ;-)
I guess 100% compatibility is a must... but I guess
performance/stability issues are inevitable.
I think maintaining this kind of thing isn't at all troublesome, most
of the stuff will be handled by CVS although we may get some conflict
at times... To accept a patch, just wrap them around #ifdef's, make
appropriate configure entries... then "publish"... (is it this easy?)
keeping up with the latest PHP might be an issue, so I guess it might
be more feasible to just merge with point releases only... (?)
Well, Firefox has greasemonkey.... we'll have powermonkey [sort of] ;-)
--
Hendy Irawan
http://www.gauldong.net
http://dev.gauldong.net
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)
This was suggested before, and declined. Please search the archives.
Derick
Derick Rethans wrote:
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)This was suggested before, and declined. Please search the archives.
Derick
As far as I remember this was brought to the list first by Thies and later
by me, back in the days when PHP 5 was still on the design table. It was said
that it is so late, and should wait for PHP 6 :) . PHP 5 took 4 years after PHP 4.
So PHP 6 may take another 5 years after PHP 5 -> 2009 :).
Andrey