Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58543
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.180.99.100 as permitted sender) client-ip=10.180.99.100;
MIME-Version: 1.0
In-Reply-To: <CAJzDObeLaAcow03cri3t62ayqCu5K3-TdeT6E0hu6jcKy95mcA@mail.gmail.com>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
	<CAMyk_AaJ4dq7ArVQ8ouubEB0yGmARZqzaD2Axv0_3vq3+WgkeQ@mail.gmail.com>
	<CAAyV7nFrhOEkOyZb28g0hq5_=yt4XeEfxm00Te=ygivYVs497Q@mail.gmail.com>
	<CAJzDObeLaAcow03cri3t62ayqCu5K3-TdeT6E0hu6jcKy95mcA@mail.gmail.com>
Date: Fri, 2 Mar 2012 22:08:27 -0500
Message-ID: <CAAyV7nGFMWfa4jdxcbDs_0rN2VbFCKU3a-P6cb3Ht3WYhduzXQ@mail.gmail.com>
To: Adam Jon Richardson <adamjonr@gmail.com>
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)

Hey all,

Here's a much more robust and updated patch (actually, it seems good
to go to me, but needs significant review)...
https://gist.github.com/1963999

One potential issue is that it requires an API change to
zend_verify_arg_type (which appears to only be called in zend_vm_def.h
- and by generation zend_vm_execute.h)...  Otherwise, it's functional
from my perspective...

Here's what's implemented:

The following cast syntaxes to the parameter type hints:
(int)
(float)
(bool)
(string)
(array)
(object)

Basically, they behave exactly as the normal cast works.  So it won't
error except in odd edge cases (for example, passing StdClass object
into (string)...

So, based on that:

function ((int) $i) {}

is identical to:

function ($i) {
    $i =3D (int) $i;
}

Additionally, the last 2 are a bit more interesting, as they will cast
it to an array/object if necessary.

To be honest, I'm not as sold on this version (I built it as a POC,
but to see how useful it is).  It feels like it's not doing "enough".
All it really does is save 6 characters.

Instead, I think I'd rather see it check for a clean cast, and at
least throw an error on unclean cast (casting (int) "foo" in this
context).  However, that's not how the current cast handler works, so
that's not what this does.

Any feedback?

Thanks,

Anthony


On Fri, Mar 2, 2012 at 3:15 PM, Adam Jon Richardson <adamjonr@gmail.com> wr=
ote:
> On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara <ircmaxell@gmail.com> wro=
te:
>>
>> 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...
>>
>> 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))...
>>
>> 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.
>>
>> 4. What about consistency? Well, there currently is no consistency.
>> Internal function parameters behave one way, and explicit casts behave
>> another. =A0And even more confusing implicit casts behave yet another
>> way ($a + $b). =A0So to implement this, we'd need to be consistent with
>> one of them. =A0Frankly, I would only want to add consistency to
>> internal function parameters, since the explicit cast is not useful
>> IMHO (it's identical to $bar =3D (int) $bar), at which point it's not
>> worth adding to save only that one line. =A0But if we're consistent with
>> internal function parameter checking, then it becomes quite useful.
>> We can throw warnings on unclean conversion and prevent execution of
>> the function... =A0That way, all function calls behave the same (as much
>> as I hate the concept of warnings on type hint failure)... =A0So, in
>> that case, function calls become an implicit cast to the type, which
>> is then why the stricter error handling (without breaking the spirit
>> or consistency).
>>
>> 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.
>>
>> Thoughts? =A0Should I update the patch to be more inline with what I
>> said above (the implicit hints that are offered by the current
>> internal function argument mechanism:
>>
>> # sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =3D "1";
>> var_dump(foo($a));'
>> int(1)
>>
>> # sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =3D
>> "foo"; var_dump(foo($a));'
>>
>> Warning: Argument 1 passed to foo() must be of the type integer,
>> string given, called in Command line code on line 1 and defined in
>> Command line code on line 1
>>
>> However, since it's not raising a terminating error, more changes
>> would need to be made to the VM to check the return status of the
>> argument check (which is currently ignored) to determine if to proceed
>> with the function call, or just return null imediately...
>>
>> Thoughts?
>
>
> Well, this seems like a reasonable approach (at least in terms of general
> discussion.)
>
> I would suggest option a), for if it looks like the same type of cast fou=
nd
> within the body of functions. I believe users will expect it to act the s=
ame
> way, too. Keeping track of two different cast behaviors would add to the
> likelihood of misusing one or the other. Additionally, previous proposals
> have struggled due to the impedance mismatch perceived between the propos=
ed
> hinting solutions and PHP's intrinsic typing qualities. Keeping things cl=
ose
> to the current modus operandus seems like it gives the proposal more chan=
ce
> of becoming a reality.
>
> I would also suggest that array not be included, if only to limit the sco=
pe
> of the current proposal and simplify the offering. It could always be add=
ed
> later. However, if it led to an increased likelihood of being
> considered/passed for some reason, then include it :)
>
> Nice work, Anthony.
>
> I am curious what some of the core developers who've been opposed to scal=
ar
> type hinting in the past would think of this approach. Zeev, Stas, others=
,
> would this be worth any consideration? It seems like an approach that is
> potentially more consistent with PHP's typing mechanisms.
>
> Thoughts?
>
> Adam