Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68927
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <522A47BC.30100@nebm.ist.utl.pt>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<522A47BC.30100@nebm.ist.utl.pt>
Date: Fri, 6 Sep 2013 23:54:47 +0200
Message-ID: <CAF+90c_Qz9afwZTdMuYpGRtfX+xww=cYMsXP9Nt=UUTPrH-oDA@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01175f3146da4c04e5be16bd
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--089e01175f3146da4c04e5be16bd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrot=
e:

> I like the idea, but I think you're approaching this the wrong way. In my
> opinion, you should emulate the current behavior as close as possible. Fo=
r
> instance:
>
>  func_get_args() will not include the missing offsets in the resulting
>> array
>>
>
> Why not? Why not include the default value in the missing offset? This is
> not possible for internal functions, but I've talked in depth about the
> problems that skipping parameters introduces and they're not different he=
re
> (though I should say those problems are not intractable and I think the
> cost/benefit analysis here is completely different).
>
>  func_get_arg($n) will throw its usual =93Argument %ld not passed to
>> function=94 warning and return false
>>
>
> Again, why not return the default value?
>

These suggestions sound very reasonable. It would require some way to get
the default value though. So unless we want to start storing them in the
arginfo (meh), I'd have to extract them from the ZEND_RECV_INIT opcodes.
Which probably is okay, as we're already doing it in Reflection.


> This section is also problematic:
>
>  All three functions are also oblivious to the collection of unknown
>> named arguments by variadics. func_get_args() will not return the
>> collected values and func_num_args() will not include them in the
>> argument count.
>>
>> (...)
>>
>
> I think the correct course of action is just to drop support for extra
> named arguments. Just add an extra array argument to the function and you
> have equivalent functionality without having to go through these edge cas=
es.
>

Dunno, personally I don't have a strong need for the extra named args.
That's something Stas considered important (in the discussing re skipparams
RFC). Would be interesting to know for what they are currently used in
Python/etc and whether those use cases are sufficiently important to us.


> I also disagree about your idea about how to handle changed parameter
> names. Having an E_ERROR here is absolutely unacceptable. This would be a
> major BC break (not to mention inconsistent with the other other signatur=
e
> mismatches are handled).


Yes, I certainly do not want to throw any fatal-ish error here. Maybe I
didn't make that clear in the RFC. (What do you mean with "inconsistent
with the other other signature mismatches are handled" though? For
signature mismatches involving interfaces we currently use fatal error.
Signature mismatches between classes are E_STRICT.)


> In fact, I think ANY message here would waste millions of $currency in ma=
n
> hours. I can't think of any easy solution there. An alternative solution
> would be to keep a flag on whether argument names changed and refuse to
> accept named arguments in the case a call is made to an instance whose
> class or some its parents changed parameter names, but this comes with so=
me
> memory penalty.
>

Eh, I don't know. Getting an error at the call-site is already too late.
You'll get one anyway because the parameter name doesn't exist. Unless
mismatching parameter names are exceedingly common, I'd think a lowly
E_STRICT level error would be bearable.

Nikita

--089e01175f3146da4c04e5be16bd--