Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
Received-SPF: pass (google.com: domain of linepogl@gmail.com designates 10.101.128.12 as permitted sender) client-ip=10.101.128.12;
MIME-Version: 1.0
In-Reply-To: <CAJWj5+EOCVbVgyOko1Zab5EMYnk3_dP7-BK22BhPCam+Fv6BXg@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>
Date: Mon, 5 Mar 2012 20:12:19 +0100
Message-ID: <CAMyk_Aa=NQk8sJatdS-YyFjDX2NC3VwQzZ=D2hsLwJdDYSvTcg@mail.gmail.com>
To: Simon Schick <simonsimcity@googlemail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e68dbb74bb025a04ba83b5da
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: linepogl@gmail.com (Lazare Inepologlou)

--0016e68dbb74bb025a04ba83b5da
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> 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 is=
 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 no=
t
>> be bothered with that at all. Instead, we could expand the type juggling
>> 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 to
>> 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. T=
he
>> first that comes to my mind is reading from a database, in cases that th=
e
>> value of null totally different than the value of 0.
>>
>> $parent_id =3D (int?) $db['PARENT_ID'];  // null and 0 mean different th=
ings
>> here...
>>
>> A second example is reading from the query string:
>>
>> $id =3D (int?) @$_GET['id'];   // the error-silencing operator will retu=
rn
>> 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 converts
>> > >> 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 it
>> > >> 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 attemp=
t
>> > >> to cast.  But my question would be: what would attempt to cast mean=
?
>> > >> 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 silentl=
y
>> > >> 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 val=
ue
>> > > to a function/method call.
>> > >
>> > > <snip>
>> > >
>> > >> 5. What about BC breaks?  Well, this entire patch (up to this point=
)
>> > >> wouldn't require one.  it's only adding the casting functionality
>> > >> (which is not implemented today), so no problem.  Existing code wou=
ld
>> > >> still function fine.
>> > >
>> > > This is something that should be highlighted. I've seen a lot of fol=
ks
>> > > claiming type hinting is viral, and the arguments make no sense to m=
e.
>> > > What your patch is offering is _opt_in_ type casting of
>> function/method
>> > > arguments. You don't _have_ to write your functions or methods using
>> > > 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
>> >
>> >
>>
>
>

--0016e68dbb74bb025a04ba83b5da--