Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60175
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJzDObc0CmXcgNq_31=hQMopz4RcSODbMMDH23yVV6Gsb-RBnA@mail.gmail.com>
References: <4F8DF4B1.2040307@sugarcrm.com> <CAAAa2sjJax_pFRTacdVmZsAs7BkBF8yhCpGmw7xmgXHT+kMBvQ@mail.gmail.com>
 <CAJzDObc0CmXcgNq_31=hQMopz4RcSODbMMDH23yVV6Gsb-RBnA@mail.gmail.com>
Date: Wed, 18 Apr 2012 10:25:19 +0100
Message-ID: <CA+yzxZiGeG1_ZQB2VNaLOsPbQ3yMC7E359jXwJy9QpYEMcs6Vw@mail.gmail.com>
To: Adam Jon Richardson <adamjonr@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] skipping optional parameters
From: admacedo@gmail.com (Daniel Macedo)

I'll keep going offtopic a bit more.
I would rather see named parameters implemented *prior* to this.
Although maybe not instead, I think both might have their place.

On Wed, Apr 18, 2012 at 08:43, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> Something like
>
> setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );
>
> is really nice to have. Source code will be much more readable.
>

I agree with this!=A0But for short array syntax we kept the =3D>=A0as in
$array =3D ["foo" =3D> "bar"];
Not sure if this was a limitation, lack of that suggestion or a
decision; but the shortest syntax it's still not... (as Yoda would
say!)

$array =3D ["foo": "bar"]; doesn't look weird to me, plenty readable,
and that's the shortest!

> This is getting off-topic, but while we're here, I think:
>
> setcookie($name =3D> 'mycookie', $value =3D> 'abc');

Not sure what the optimal PHP syntax should be for named parameters,
but I think this isn't it.


Back to the topic at hand.
There doesn't need to be a lot of parameters on a function for this to
be useful, even with IDE assistance.

For a proper refactoring, where you'd only needing to change the
function definition. In calls where the optional parameters would call
a 'default', they should in fact be the default. Where as now we'd
have to go through all the function calls for any case where we
statically used the default and change it to the new default...

But I couldn't support the comma train, for the insane =ABlots of
parameters=BB case, would hate to read some fn($some,,,, $var,,, $other)
call.
I'd rather reuse a reserved word like 'default' (or even get a shorter one?=
)