Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58850
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C379A30D-3B12-4C2B-B3A0-0B4D1B92BC44@gmail.com>
References: <CAAyV7nHOwCoci6W7-cvFEJi27Wz7qA-_0a6_qHVyzwkC6rjWQQ@mail.gmail.com>
	<CAMyk_AY-vYp_VbctGomyKN0fra0QU3E=rRmacazrRDWeZNgHPg@mail.gmail.com>
	<CAAyV7nHZohu1rkuLFdzAdD_JX3jgVJcfkxbdc6ZnuUCSvEGnJA@mail.gmail.com>
	<CAMyk_AZuhgmsb8ONpW3kYV7FgwBr4csGs+xoDrEt=c=c-PtvEA@mail.gmail.com>
	<CAJWj5+E8KSXzugb6xz+xm26WMPNxdoSaS14cZ8vpxYF2GCT7qw@mail.gmail.com>
	<CAMyk_AaOKOD1=Fxj=4iY56P7gCxb410hg_x9dER8qiTjnpvUTA@mail.gmail.com>
	<C379A30D-3B12-4C2B-B3A0-0B4D1B92BC44@gmail.com>
Date: Sun, 11 Mar 2012 21:50:12 -0400
Message-ID: <CAAyV7nF9GDAN4f92+XkKjLAGnZ4KukFOt0uMf2=hyA38M0YS2A@mail.gmail.com>
To: Tjerk Meesters <tjerk.meesters@gmail.com>
Cc: Lazare Inepologlou <linepogl@gmail.com>, Simon Schick <simonsimcity@googlemail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
From: ircmaxell@gmail.com (Anthony Ferrara)

Ok, so it looks like we've had some decent conversation, but it has
started to tail off a bit.  I'd normally draft an RFC at this point,
but it seems there's still some contention on how exactly the
implementation should work.

Personally, if we're going to go for any form of strict checking
(meaning not blind-conversion), I will not support these hint rules
diverging from zend_parse_parameters (internal functions).  It just
creates a new layer of inconvenience and confusion for not a whole lot
of gain.  When I say divergence from ZPP, I'm talking about the same
behavior when ZPP returns SUCCESS, and a E_RECOVERABLE_ERROR when ZPP
returns FAILURE...

Now, with that said, I'd be all for making sane changes to ZPP to
bring both inline with a common goal.  Think that passing "1abc" to an
int type hinted parameter (which currently raises a notice) is
unacceptable?  Then my opinion is that it should be tightened in both
places at the same time.  But they should stay connected as closely as
possible for consistency...

So, with that said, let me ask this question:  What needs to change
from the current POC before it can be formalized into an RFC?  Do we
need to tighten the conversions?  Or are they OK as-is?

Thoughts?

Anthony

On Sat, Mar 10, 2012 at 2:45 AM, Tjerk Meesters
<tjerk.meesters@gmail.com> wrote:
>
> On 9 Mar, 2012, at 11:20 PM, Lazare Inepologlou <linepogl@gmail.com> wrote:
>
>> Type casting combined with passing by reference is problematic in many
>> ways. Just an example:
>>
>> fuction foo( string & $buffer) { ... }
>> foo( $my_buffer );
>>
>> Here, $my_buffer has just been declared, so it is null. Should this be an
>> error? I don't know! So, I think that that passing by reference should not
>> be (immediately) supported.
>>
>
> Strictly speaking, if you add a type to a referenced variable in that way it's only logical that you expect it to have a proper value when the function is called. After all, it's not an output type declaration :)
>