Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58603
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.224.182.201 as permitted sender) client-ip=10.224.182.201;
MIME-Version: 1.0
In-Reply-To: <E5.D1.35539.16BD45F4@pb1.pair.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>
Date: Mon, 5 Mar 2012 10:45:11 -0500
Message-ID: <CAAyV7nEn8saaiSmJjRNvmo06fg_BmsH3vbQXfOJYBNdq7HQtNQ@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: ircmaxell@gmail.com (Anthony Ferrara)

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. =A0Where 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? =A0Perhaps. =A0So at that point, foo(arr=
ay
>> $bar) would do a "strict" check, and foo((array) $bar) would attempt
>> to cast. =A0But my question would be: what would attempt to cast mean?
>> Should it error out if you pass foo(1)? =A0That's what the internal
>> function cast rules do. =A0And 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:
>
> =A0 =A0function foo($bar)
> =A0 =A0{
> =A0 =A0 =A0 =A0$bar =3D (array) $bar;
> =A0 =A0}
>
> 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:
>
> =A0 =A0function foo((array) $bar)
> =A0 =A0{
> =A0 =A0}
>
> It's casting, and clearly different than:
>
> =A0 =A0function foo(array $bar)
> =A0 =A0{
> =A0 =A0}
>
> which is doing a typehint check.
>
>> 3. Should references be supported? =A0My 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? =A0Well, this entire patch (up to this point)
>> wouldn't require one. =A0it's only adding the casting functionality
>> (which is not implemented today), so no problem. =A0Existing 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 =A0 =A0 =A0 =A0 =A0 =A0| matthew@zend.com
> Zend Framework =A0 =A0 =A0 =A0 =A0| 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
>