Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58827
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: <A633CF2D7C7BED41B41F1E64F25507B8069DC4733F@MAILR001.mail.lan>
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>
 <CAJWj5+E6O3B_M_SQrq-z5tJsLgc6PKODj6UGme7guV9qkJX3QA@mail.gmail.com> <A633CF2D7C7BED41B41F1E64F25507B8069DC4733F@MAILR001.mail.lan>
Date: Sat, 10 Mar 2012 00:32:10 +0100
Message-ID: <CAMyk_AZspXVagU31Aebn5RhROgCgzwQua6ZJRkwT-kzHcJSAKA@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: Simon Schick <simonsimcity@googlemail.com>, Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636c5bfd464739c04bad7ce7c
Subject: Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
From: linepogl@gmail.com (Lazare Inepologlou)

--001636c5bfd464739c04bad7ce7c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 > what if we added extra out and inout hints for references?

With the danger of becoming boring, I have to say that C# also support
"ref" and "out" arguments... Are we reinventing the wheel here?

To be honest, this is going too far. Can we have the basics first? Passing
by reference is a corner case, at least for PHP.



Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/9 John Crenshaw <johncrenshaw@priacta.com>

> From: Simon Schick [mailto:simonsimcity@googlemail.com]
> >
> > 2012/3/9 Lazare Inepologlou <linepogl@gmail.com>
> > >
> > > Type casting combined with passing by reference is problematic in man=
y
> ways. Just an example:
> > >
> > > fuction foo( string & $buffer) { ... } foo( $my_buffer );
> > >
> > > Here, $my_buffer has just been declared, so it is null. Should this b=
e
> an error? I don't know! So, I think that that passing by reference should
> not be (immediately) supported.
> > >
> >
> > Hi, Lazare
> >
> > This should at least throw an E_NOTICE :) And also an error as NULL is
> not allowed here.
> >
> > Let me modify your example:
> >
> > fuction foo( string & $buffer =3D NULL) { ... } foo( $my_buffer );
> >
> > This would only raise the E_NOTICE because the variable has not been
> declared.
> > Or would you say that NULL is equal with an empty string (talking about
> implicit casting)? I would not like that, but if, don't let it be (int)0 =
or
> (bool)false as well.
> >
> > Bye
> > Simon
>
> The reason you have to validate the input type in this case is because
> even though it is a reference, we don't ACTALLY know that it isn't suppos=
ed
> to contain an input (even though that would be against all sane rules mos=
t
> of the time).
>
> I'm not attached to this idea at all, but I thought I'd throw it out and
> see if anyone can think of a problem with it; what if we added extra out
> and inout hints for references?
>
> // So this would give no error at all. Parameter is anticipated to be for
> output. Just silently change the type and don't warn on anything.
> fuction foo( out string & $buffer) { ... } foo( $my_buffer );
>
> // This WOULD give an error, because the parameter is also an input
> parameter:
> fuction foo( inout string & $buffer =3D NULL) { ... } foo( $my_buffer );
>
> // In any case no errors on these:
> fuction foo( inout string & $buffer =3D NULL) { ... } foo(
> (string)$my_buffer );
> fuction foo( string & $buffer =3D NULL) { ... } foo( (string)$my_buffer )=
;
>
> If we assumed that all references were out unless stated otherwise we
> could avoid reserving an "out" keyword, and only add "inout", which is
> unlikely to conflict with stuff.
>
> Like I said, no attachment to this at all. My gut tells me I may have
> missed something really stupid here. Just brainstorming.
>
> John Crenshaw
> Priacta, Inc.
>

--001636c5bfd464739c04bad7ce7c--