Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58617
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.155.68 as permitted sender) client-ip=10.182.155.68;
MIME-Version: 1.0
In-Reply-To: <CAMyk_Aa=NQk8sJatdS-YyFjDX2NC3VwQzZ=D2hsLwJdDYSvTcg@mail.gmail.com>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
	<CAMyk_AaJ4dq7ArVQ8ouubEB0yGmARZqzaD2Axv0_3vq3+WgkeQ@mail.gmail.com>
	<CAAyV7nFrhOEkOyZb28g0hq5_=yt4XeEfxm00Te=ygivYVs497Q@mail.gmail.com>
	<E5.D1.35539.16BD45F4@pb1.pair.com>
	<CAAyV7nEn8saaiSmJjRNvmo06fg_BmsH3vbQXfOJYBNdq7HQtNQ@mail.gmail.com>
	<CAMyk_AYCZwU7VHo7W_Ta891z=REUbAyzPriCTtxPe=x8W8pnOQ@mail.gmail.com>
	<CAJWj5+EOCVbVgyOko1Zab5EMYnk3_dP7-BK22BhPCam+Fv6BXg@mail.gmail.com>
	<CAMyk_Aa=NQk8sJatdS-YyFjDX2NC3VwQzZ=D2hsLwJdDYSvTcg@mail.gmail.com>
Date: Mon, 5 Mar 2012 20:16:09 +0100
Message-ID: <CAJWj5+G=AXTh7dpoZey2nX4ChzFPb6y+7An1QBCAYuKo3wTUUQ@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d044784973c88a304ba83c229
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: simonsimcity@googlemail.com (Simon Schick)

--f46d044784973c88a304ba83c229
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Lazare

Sorry, I've only looked at your first array-example :)

Bye
Simon

2012/3/5 Lazare Inepologlou <linepogl@gmail.com>

>  In your examples you are accessing an maybe non-existing array-key
>
>
> Yes, this is why I used the error silencing (@) operator. But anyway, it
> is irrelevant to the whole proposal.
>
> Lazare INEPOLOGLOU
> Ing=C3=A9nieur Logiciel
>
>
>
> 2012/3/5 Simon Schick <simonsimcity@googlemail.com>
>
>> Hi, Lazare
>>
>> In your examples you are accessing an maybe non-existing array-key.
>> This will raise an E_NOTICE. See the note below this example:
>> http://php.net/manual/en/language.types.array.php#example-85
>>
>> Maybe you also want something like that:
>> isset($x) ? (is_null($x) ? null : (int)$x) : null
>>
>> But let's discuss that in a different thread.
>>
>> Bye
>> Simon
>>
>> 2012/3/5 Lazare Inepologlou <linepogl@gmail.com>
>>
>>> Anthony,
>>>
>>> I still don't like the null-as-a-default-value solution. I find it
>>> confusing.
>>>
>>> I know that something similar appears in class type hinting, but:
>>> 1. Class type hinting does not do casting (yet).
>>> 2. Apart from null, no other value could be placed anyway. (Even that i=
s
>>> a
>>> little bit wrong as null belongs to a different type than the hinted
>>> class).
>>>
>>> -------
>>>
>>> I have a different proposal. The argument type hinting/casting should n=
ot
>>> be bothered with that at all. Instead, we could expand the type jugglin=
g
>>> system a little bit, with the introduction of a special type of casting
>>> that leaves null unchanged. Something like this:
>>>
>>> (int?) $x
>>>
>>> which should be strictly translated to the following, without any way t=
o
>>> change that behavior by any type casting overload system:
>>>
>>> is_null($x) ? null : (int)$x
>>>
>>> Examples:
>>>
>>> (int?) 13           // 13
>>> (int?) ''           // 0
>>> (int?) 0            // 0
>>> (int?) null         // null
>>> (int?) '342.3Test'  // 342
>>>
>>> I can think of many real world scenarios that could benefit from this.
>>> The
>>> first that comes to my mind is reading from a database, in cases that t=
he
>>> value of null totally different than the value of 0.
>>>
>>> $parent_id =3D (int?) $db['PARENT_ID'];  // null and 0 mean different
>>> things
>>> here...
>>>
>>> A second example is reading from the query string:
>>>
>>> $id =3D (int?) @$_GET['id'];   // the error-silencing operator will ret=
urn
>>> null on error.
>>>
>>>
>>> Thoughts?
>>>
>>>
>>> Lazare INEPOLOGLOU
>>> Ing=C3=A9nieur Logiciel
>>>
>>>
>>> 2012/3/5 Anthony Ferrara <ircmaxell@gmail.com>
>>>
>>> > Matthew,
>>> >
>>> > Have you seen the new thread and RFC around this?
>>> > https://wiki.php.net/rfc/parameter_type_casting_hints
>>> >
>>> > I went with option A, as I see erroring on cast as a more general
>>> > problem.  So for consistency, I implemented it exactly like normal
>>> > explicit casts...
>>> >
>>> > Anthony
>>> >
>>> > On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
>>> > <weierophinney@php.net> wrote:
>>> > > On 2012-03-02, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>>> > >> Well, there are a few questions about the implementation:
>>> > >>
>>> > >> 1. *Which* type casting rules should it follow?
>>> > >>
>>> > >> a. Regular cast rules (like $foo =3D (int) $foo), where it convert=
s
>>> > >> always without error?
>>> > >> b. Internal function cast rules, where it warnings on error and
>>> > >> prevents execution of the function.
>>> > >> c. Current type hinting rules, where if it can't convert cleanly i=
t
>>> > >> E_RECOVERABLE_ERRORS
>>> > >>
>>> > >> Personally, I like C the best.  Where if it is passed an invalid
>>> > >> value, it attempts to cleanly convert, but errors out if it can't.=
..
>>> > >> But I can see other arguments being made...
>>> > >
>>> > > (c) seems the most sane option ot me as well.
>>> > >
>>> > >> 2. Should (array) be supported?  Perhaps.  So at that point,
>>> foo(array
>>> > >> $bar) would do a "strict" check, and foo((array) $bar) would attem=
pt
>>> > >> to cast.  But my question would be: what would attempt to cast mea=
n?
>>> > >> Should it error out if you pass foo(1)?  That's what the internal
>>> > >> function cast rules do.  And to me that's more obvious than silent=
ly
>>> > >> converting it to foo(array(1))...
>>> > >
>>> > > Turn this around and look at it from the current state of PHP:
>>> > >
>>> > >    function foo($bar)
>>> > >    {
>>> > >        $bar =3D (array) $bar;
>>> > >    }
>>> > >
>>> > > If you pass a value of 1 for $bar, $bar is then converted to
>>> array(1).
>>> > > That's what I'd expect the following to do as well:
>>> > >
>>> > >    function foo((array) $bar)
>>> > >    {
>>> > >    }
>>> > >
>>> > > It's casting, and clearly different than:
>>> > >
>>> > >    function foo(array $bar)
>>> > >    {
>>> > >    }
>>> > >
>>> > > which is doing a typehint check.
>>> > >
>>> > >> 3. Should references be supported?  My feeling is yes, they should=
.
>>> > >> So if you do foo((array) &$bar), it would cast the original value
>>> (if
>>> > >> possible) as well.
>>> > >
>>> > > I personally would expect casting and references to be mutually
>>> > > exclusive -- if you're casting, you're changing the value type, and=
 I
>>> > > wouldn't expect a destructive operation like this from passing a
>>> value
>>> > > to a function/method call.
>>> > >
>>> > > <snip>
>>> > >
>>> > >> 5. What about BC breaks?  Well, this entire patch (up to this poin=
t)
>>> > >> wouldn't require one.  it's only adding the casting functionality
>>> > >> (which is not implemented today), so no problem.  Existing code
>>> would
>>> > >> still function fine.
>>> > >
>>> > > This is something that should be highlighted. I've seen a lot of
>>> folks
>>> > > claiming type hinting is viral, and the arguments make no sense to
>>> me.
>>> > > What your patch is offering is _opt_in_ type casting of
>>> function/method
>>> > > arguments. You don't _have_ to write your functions or methods usin=
g
>>> > > them, and for those who do, it should have no side effects on code
>>> > > calling it.
>>> > >
>>> > > I would _LOVE_ to see this as part of PHP.
>>> > >
>>> > > --
>>> > > Matthew Weier O'Phinney
>>> > > Project Lead            | matthew@zend.com
>>> > > Zend Framework          | http://framework.zend.com/
>>> > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>> > >
>>> > > --
>>> > > PHP Internals - PHP Runtime Development Mailing List
>>> > > To unsubscribe, visit: http://www.php.net/unsub.php
>>> > >
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>
>>
>

--f46d044784973c88a304ba83c229--