Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58615
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.147.106 as permitted sender) client-ip=10.182.147.106;
MIME-Version: 1.0
In-Reply-To: <CAMyk_AYCZwU7VHo7W_Ta891z=REUbAyzPriCTtxPe=x8W8pnOQ@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>
Date: Mon, 5 Mar 2012 19:43:44 +0100
Message-ID: <CAJWj5+EOCVbVgyOko1Zab5EMYnk3_dP7-BK22BhPCam+Fv6BXg@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04446c574e3aa504ba834e8e
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: simonsimcity@googlemail.com (Simon Schick)

--f46d04446c574e3aa504ba834e8e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 not
> 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. Th=
e
> first that comes to my mind is reading from a database, in cases that the
> value of null totally different than the value of 0.
>
> $parent_id =3D (int?) $db['PARENT_ID'];  // null and 0 mean different thi=
ngs
> here...
>
> A second example is reading from the query string:
>
> $id =3D (int?) @$_GET['id'];   // the error-silencing operator will retur=
n
> 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(arr=
ay
> > >> $bar) would do a "strict" check, and foo((array) $bar) would attempt
> > >> 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 silently
> > >> 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 (i=
f
> > >> 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 valu=
e
> > > 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 woul=
d
> > >> still function fine.
> > >
> > > This is something that should be highlighted. I've seen a lot of folk=
s
> > > 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/meth=
od
> > > 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
> >
> >
>

--f46d04446c574e3aa504ba834e8e--