If you have too many parameters that you want to start omitting
parameters when calling a function, its probably time to refactor.
And if you have many parameters to functions you still need to look at the
definition (or documentation) to figure out what parameters the function
takes. It's not a big problem to look at the order at the same time.
- Frank
Frank M. Kromann wrote:
And if you have many parameters to functions you still need to look at the
definition (or documentation) to figure out what parameters the function
takes. It's not a big problem to look at the order at the same time.
lets face the opposite direction for a second:
all those string functions with different order of haystack and needle
named parameters could help to reduce the criticism we get for this
poor choice of parameter order in the past ...
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
Hartmut, there are only 2 or 3 of those functions where the order
differs.
-Andrei
Frank M. Kromann wrote:
And if you have many parameters to functions you still need to
look at the
definition (or documentation) to figure out what parameters the
function
takes. It's not a big problem to look at the order at the same time.lets face the opposite direction for a second:
all those string functions with different order of haystack and needle
named parameters could help to reduce the criticism we get for this
poor choice of parameter order in the past ...--
Hartmut Holzgraefe, Senior Support
Engineer .
MySQL AB, www.mysql.com
Andrei Zmievski wrote:
Hartmut, there are only 2 or 3 of those functions where the order differs.
but it's the fact that it differs at all that counts ...
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins,
limit: 10);
It's nice to be able to stick to what matters, and omit everything that
doesn't matter (ordinary joins, where, group by, having).
With func_get_args() returning an associative array, one could also, for
example, generate html tags (with parameters being attribute names with
their values).
Named parameters would add a lot of flavor, while being 100% backward
compatible.
- Ron
"Hartmut Holzgraefe" hartmut@php.net wrote in message
news:43C69B2A.8000802@php.net...
Andrei Zmievski wrote:
Hartmut, there are only 2 or 3 of those functions where the order
differs.but it's the fact that it differs at all that counts ...
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
Ron Korving wrote:
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins,
limit: 10);
We've seen a large number of cases where named parameters would be
extremely useful. To each case, there has been a half baked attempt to
dismiss the usefulness of the purported design.
For example,
If you have too many parameters that you want to start omitting
parameters when calling a function, its probably time to refactor.
Refactor? If you have a number of required options to get a result,
refactoring isn't going to change that.
Also,
And if you have many parameters to functions you still need to look at
the definition (or documentation) to figure out what parameters the
function takes. It's not a big problem to look at the order at the
same time.
That's not the point, at all. It annoys me that good points are being
dismissed with such ridiculous counter-arguments.
No one is suggesting that people shouldn't look at the definition. Nor
that people have problems remembering parameter order (I do, but again,
not the point). In fact, named parameters allows people to quickly look
at the definition to see what options are available. This is one reason
named parameters are an improvement on associative array parsing.
The problem is when an option needs to be changed which just happens to
be at the very end of the function signature, function calls start
looking like this: foo(null, null, null, null, null, null, true);
Anyway, enough rebuttal. I think it's now incredibly obvious that the
wider community would like to see named parameters in PHP 6.
Are the PHP group prepared to accept and implement a named parameters patch?
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named parameters
patch?
As far as I am concerned it would depend on the patch. If you can come
up with a way to do it with requiring rewriting all 4000+ functions out
there, go for it.
-Rasmus
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named parameters patch?
As far as I am concerned it would depend on the patch. If you can
come up with a way to do it with requiring rewriting all 4000+
functions out there, go for it.
As Andi said, that's hardly the big issue (we could have provided it
as a userland feature, not applicable to internal functions, or
applicable to just a small subset of them).
The big issue is whether or not we want that feature in the language,
and the answer appears to be no.
Zeev
Zeev Suraski wrote:
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named parameters
patch?As far as I am concerned it would depend on the patch. If you can
come up with a way to do it with requiring rewriting all 4000+
functions out there, go for it.As Andi said, that's hardly the big issue (we could have provided it as
a userland feature, not applicable to internal functions, or applicable
to just a small subset of them).The big issue is whether or not we want that feature in the language,
and the answer appears to be no.
Well, having half of a feature like that by only making it work in some
places is what I think many folks are against. I don't think the answer
is no if we had a clean and consistent way to implement it. I would
certainly be all for it in that case.
-Rasmus
At 12:37 15/01/2006, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named
parameters patch?As far as I am concerned it would depend on the patch. If you can
come up with a way to do it with requiring rewriting all 4000+
functions out there, go for it.
As Andi said, that's hardly the big issue (we could have provided
it as a userland feature, not applicable to internal functions, or
applicable to just a small subset of them).
The big issue is whether or not we want that feature in the
language, and the answer appears to be no.Well, having half of a feature like that by only making it work in
some places is what I think many folks are against. I don't think
the answer is no if we had a clean and consistent way to implement
it. I would certainly be all for it in that case.
Ok, so we're split. I actually don't think it's a must to have all
functions adhere to this new method of calling (I don't think it's
necessary, but even if it was - it's probably just a few days of
work). It's definitely not the implementation which is the problem,
as with other cases, we have enough bright people on board here that
could figure it out if we wanted to go ahead with it.
It's adding another core level feature that's useful in very rare
cases, and that adds another layer of complexity, that is the problem
in my (and many others') opinion. And it becomes even much worse if
we support it throughout the entire language, as it means it'll
become popular not only in these rare cases where it's really useful,
but throughout everyday usage (as is the case with about anything,
some people prefer one way of doing things, and others prefer another).
Thankfully, regardless of the reasoning, the bottom line is no.
Zeev
Zeev, I agree with you that if this is implemented throughout the engine, it
would actually not make things better. Some people will be doing
strpos(needle: $needle, haystack: $haystack) and others will be doing
strpos($haystack, $needle) and PHP will grow to a situation where half the
people are doing A and half the people are doing B. I fear that would be
very much for the worse. So, personally, I've come to the conclusion that it
would be best if it existed as a userland feature only that people can use
for those occasions where it might actually be useful.
- Ron
"Zeev Suraski" zeev@zend.com wrote in message
news:7.0.1.0.2.20060115135052.05c1b848@zend.com...
At 12:37 15/01/2006, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named
parameters patch?As far as I am concerned it would depend on the patch. If you can
come up with a way to do it with requiring rewriting all 4000+
functions out there, go for it.
As Andi said, that's hardly the big issue (we could have provided
it as a userland feature, not applicable to internal functions, or
applicable to just a small subset of them).
The big issue is whether or not we want that feature in the
language, and the answer appears to be no.Well, having half of a feature like that by only making it work in
some places is what I think many folks are against. I don't think
the answer is no if we had a clean and consistent way to implement
it. I would certainly be all for it in that case.Ok, so we're split. I actually don't think it's a must to have all
functions adhere to this new method of calling (I don't think it's
necessary, but even if it was - it's probably just a few days of
work). It's definitely not the implementation which is the problem,
as with other cases, we have enough bright people on board here that
could figure it out if we wanted to go ahead with it.It's adding another core level feature that's useful in very rare
cases, and that adds another layer of complexity, that is the problem
in my (and many others') opinion. And it becomes even much worse if
we support it throughout the entire language, as it means it'll
become popular not only in these rare cases where it's really useful,
but throughout everyday usage (as is the case with about anything,
some people prefer one way of doing things, and others prefer another).Thankfully, regardless of the reasoning, the bottom line is no.
Zeev
PHP will grow to a situation where half the
people are doing A and half the people are doing B. I fear that would be
very much for the worse.
Where were all these arguments when PHP was changed to become Java Jr.?
I agree that if implemented this feature should be all or nothing. If
its only userland, it is confusing to new users. But, I really to find
it upsetting to see so many people saying that this feature will
fracture the PHP community. Those with CVS access have already put
things (like all the OO functionality) in that have fractured the user
base already IMO.
Brian Moon
Phorum Dev Team
Brian Moon wrote:
PHP will grow to a situation where half the
I agree that if implemented this feature should be all or nothing. If
its only userland, it is confusing to new users. But, I really to find
it upsetting to see so many people saying that this feature will
fracture the PHP community. Those with CVS access have already put
things (like all the OO functionality) in that have fractured the user
base already IMO.
Oh come on. OO was needed if php was ever to be taken seriously as an
enterprise ready language. You can't however do everything in OO, so you
need to learn procedural anyway - so all the userbase still knows
procedural.
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named parameters patch?
As far as I am concerned it would depend on the patch. If you can come up
with a way to do it with requiring rewriting all 4000+ functions out there, go
^^^^
I think you meant without?
Derick
Aidan,
People often mention the 20/80 rule, we're so far away from there
that it's not even funny. It's more like the 1/99 rule, not to
mention 0.0001 / 99.9999 rule. That means that even if we could come
up with a way to improve that tiny fraction of cases, it would be
highly debatable whether we could justify adding another layer of
complexity into the language.
In those rare occurrences where named parameters have true benefits,
please live with the drawbacks of using array().
Zeev
At 09:17 15/01/2006, Aidan Lister wrote:
Ron Korving wrote:
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins,
limit: 10);We've seen a large number of cases where named parameters would be
extremely useful. To each case, there has been a half baked attempt
to dismiss the usefulness of the purported design.For example,
If you have too many parameters that you want to start omitting
parameters when calling a function, its probably time to refactor.Refactor? If you have a number of required options to get a result,
refactoring isn't going to change that.Also,
And if you have many parameters to functions you still need to look at
the definition (or documentation) to figure out what parameters the
function takes. It's not a big problem to look at the order at the
same time.That's not the point, at all. It annoys me that good points are
being dismissed with such ridiculous counter-arguments.No one is suggesting that people shouldn't look at the definition.
Nor that people have problems remembering parameter order (I do, but
again, not the point). In fact, named parameters allows people to
quickly look at the definition to see what options are available.
This is one reason named parameters are an improvement on
associative array parsing.The problem is when an option needs to be changed which just happens
to be at the very end of the function signature, function calls
start looking like this: foo(null, null, null, null, null, null, true);Anyway, enough rebuttal. I think it's now incredibly obvious that
the wider community would like to see named parameters in PHP 6.Are the PHP group prepared to accept and implement a named parameters patch?
In those rare occurrences where named parameters have true benefits,
please live with the drawbacks of using array().
I do, though code completion, type hinting, etc. would be nice. It
would nice if it was consistenly added so that built-in functions had
that behavior, since no one can use the array hack for those. But lots
of things would be nice, so I don't really care. Seems like too much
work for the benefit. And there are downsides not even mentioned in
this thread (parameter names are now seen (which is obvious, until you
really think about it), they gain longevity, language issues, etc.).
Not to mention, we might be tempted to go back and rewrite stuff and
that would not be an effecient use of our time.
But "rare occurrences"? That was pretty funny! Sadly...
Just to throw in my two cents since every one else has (not that my 2
cents is worth anything more than just that), but isn't it as easy as
doing something like the following:
(using pseudo example from above)
function db_connect($params) {
$host = 'localhost';
$user = 'root';
$password = '';
$port = 3301;
extract($params, EXTR_OVERWRITE);
// ... more code here
}
This covers the default parameters in a clean fashion which is easy to
understand and should be readable to anyone who knows PHP in even the
slightest fashion. Now to the issue of type hinting, it's as simple as
doing something like the following:
if(!($obj instanceOf ClassName)) {
throw new Exception();
}
Then you have complete control of how the error is handled (be it
exceptions, trigger_error(), etc). To me, it seems the options are a
LOT more flexible using array syntax than using actual named
parameters, but maybe that's just me. To each their own, but if it
were me, it seems the above not only is easier to use / read, but also
guaranteed to work on almost all versions of PHP (at least in the case
of the first code snippet).
--
Jeremy Johnstone
http://www.jeremyjohnstone.com
jsjohnst@php.net
Just to throw in my two cents since every one else has (not that my 2
cents is worth anything more than just that), but isn't it as easy as
doing something like the following:(using pseudo example from above)
function db_connect($params) {
$host = 'localhost';
$user = 'root';
$password = '';
$port = 3301;
extract($params, EXTR_OVERWRITE);
// ... more code here
}This covers the default parameters in a clean fashion which is easy to
understand and should be readable to anyone who knows PHP in even the
slightest fashion.
I think you should use EXTR_IF_EXISTS instead of EXTR_OVERWRITE. I guess
you don't want undefined arguments to be defined by the user.
Just adding my 2 cents too.