Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58612
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)
Received-SPF: pass (google.com: domain of linepogl@gmail.com designates 10.236.154.168 as permitted sender) client-ip=10.236.154.168;
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEn8saaiSmJjRNvmo06fg_BmsH3vbQXfOJYBNdq7HQtNQ@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>
Date: Mon, 5 Mar 2012 17:48:43 +0100
Message-ID: <CAMyk_AYCZwU7VHo7W_Ta891z=REUbAyzPriCTtxPe=x8W8pnOQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3040eb9a403e4304ba81b4f0
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: linepogl@gmail.com (Lazare Inepologlou)

--20cf3040eb9a403e4304ba81b4f0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. The
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 thing=
s
here...

A second example is reading from the query string:

$id =3D (int?) @$_GET['id'];   // the error-silencing operator will return
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 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 (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 point)
> >> 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 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
>
>

--20cf3040eb9a403e4304ba81b4f0--