Everything

php

RE: Re: Named arguments revisited

php.internals

Frank M. Kromann

20 years ago

>
> 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

Hartmut Holzgraefe

20 years ago

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

20 years ago

Hartmut, there are only 2 or 3 of those functions where the order
differs.

-Andrei

On Jan 12, 2006, at 8:49 AM, Hartmut Holzgraefe wrote:

Hartmut Holzgraefe

20 years ago

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

20 years ago

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.

Aidan Lister

20 years ago

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?

Rasmus Lerdorf

20 years ago

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

Zeev Suraski

20 years ago

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

Rasmus Lerdorf

20 years ago

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

Zeev Suraski

20 years ago

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

Derick Rethans

20 years ago

On Sat, 14 Jan 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

^^^^

I think you meant without?

Derick

Rohin Knight

20 years ago

Please forgive me if this has already been mentioned as I have only just
joined this mailing list.

Why not just have certain functions that have the option to accept 1 string
that specifies all the parameters required like the date function except
more easy to work with. For example you could use:

$query = buildQuery(select:  . $columns . , from:  . $tables . ,
leftjoin:  . $leftjoins . , limit: 10);

Instead of updating the language and making it more complex all you have to
do is modify the code in the library function so it can extract the
parameters from the string passed to the function.

Zeev Suraski

20 years ago

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:

steve roussey

20 years ago

On 1/15/06, Zeev Suraski <zeev@zend.com> wrote:

> 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...

Jeremy Johnstone

20 years ago

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

Xenon_54

20 years ago

> 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.