Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58455
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.244 as permitted sender)
To: David Muir <davidkmuir@gmail.com>, Anthony Ferrara <ircmaxell@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Date: Fri, 2 Mar 2012 00:03:59 -0500
Thread-Topic: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of
 Concept
Thread-Index: Acz4LYpTYlAmuwlASwWzE5wpeC8iyAAASWvA
Message-ID: <A633CF2D7C7BED41B41F1E64F25507B8069DC46E73@MAILR001.mail.lan>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
 <4F504D4D.6010806@gmail.com>
In-Reply-To: <4F504D4D.6010806@gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of
 Concept
From: johncrenshaw@priacta.com (John Crenshaw)

I do like retaining the same functional behavior afforded to internal funct=
ions.

Cast syntax seems awkward to me though. Some things that immediately come t=
o mind:

// ?? lossless, but wrong type. Does this cast or fail?
(function((object)$o){})(array());

// ?? If (object) is allowed, (array) seems like it would be valid too,
// but since it is also different from a straight array type hint, it
// seems like it would do something different. Does this cast or fail?
(function((array)$o){})($object);

Cast syntax differs from documentation meaning the same thing.

Cast syntax may re-open the consistency vs. BC question previously worked o=
ut.

John Crenshaw
Priacta, Inc.

On 02/03/12 14:48, Anthony Ferrara wrote:
> Hey all,
>
> I know given all the discussion about this topic lately, this is a hot=20
> topic.  But I whipped together a quick POC patch to implement scalar=20
> type casting for function parameters.  Let me describe it:
>
> Patch: https://gist.github.com/1947259
>
> Example:
>
> function foo( (int) $bar ) {
>     var_dump($bar);
> }
>
> foo(1); // int(1)
> foo("1"); // int(1)
> foo(1.5); // int(1)
> foo("foo"); // E_RECOVERABLE_ERROR - Expected integer foo(array()); //=20
> E_RECOVERABLE_ERROR
>
> Right now, I only implemented the checks for (int), but I add the=20
> parser constructs for (int), (float), (bool), (string) and (object)...
>
> Now, let's talk why I did what I did:
>
> Why did I use cast syntax?  Well, there are really three main reasons.
>  First off, to indicate that a cast may happen.  Second, to prevent=20
> needing new tokens (and hence reserved words).  And third to provide a=20
> distinction between a string class type hint and a string scalar type=20
> hint.
>
> Why did I only implement (int)?  Well, because I just wanted to build=20
> a quick dirty POC that can be executed to see the semantics of=20
> operation.  There are issues with it now, so rather than doing all the=20
> work to re-do it later, I just implemented int...
>
> Why implement (object)?  Because right now, there's no way to say you=20
> want to accept a generic object without caring about type.  So the
> (object) cast/hint would then provide that ability to accept a generic=20
> object.
>
> Why not implement (resource)?  Because that would require a new parser=20
> token, as it's not available now...
>
> How does the casting work?  Right now, it's using a copy of the same=20
> rules that internal functions use with zend_parse_parameters.  That=20
> way, it brings the operating semantics of internal functions and=20
> userland functions more inline with each other.
>
>
>
> So with that said, there are some (significant) issues with the patch:
>
> 1. First off, the arg checks happen before separation of the zval on=20
> non-referenced calls.  So that means the cast effects the original=20
> zval AND the argument.  Which is a no-go for a production patch.  So=20
> that means that the cast logic would need to be put after the zval=20
> split.  But we'd still want the checks first, so it's not too=20
> difficult to segregate, just requires deeper changes.  It's not=20
> difficult (that I can see yet), just more work...  Example of the
> problem:
>
> # sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =3D=20
> "1"; foo($a); var_dump($a);'
> int(1)
> int(1)
>
> 2.  Right now, the zend_aprse_arg_impl (=20
> http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )=20
> that's used by internal functions is defined as static.  So we'd be=20
> copying a lot of the code back and forth.  In the production patch,=20
> I'd also want to re-factor that out a bit into either functions or=20
> macros to handle the type conversion and casting in both places.  That=20
> way, both systems would behave identical (or as close as possible).
>
>
> So, with that said, what do you think?  Is this something worth=20
> pursuing?  Are there any fundamental issues that I'm missing?  What=20
> else would we need to cover in a production patch and RFC?
>
> Thanks,
>
> Anthony
>


--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:=
 http://www.php.net/unsub.php