Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58454
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.224.207.70 as permitted sender) client-ip=10.224.207.70;
MIME-Version: 1.0
In-Reply-To: <4F504D4D.6010806@gmail.com>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
	<4F504D4D.6010806@gmail.com>
Date: Thu, 1 Mar 2012 23:52:57 -0500
Message-ID: <CAAyV7nG5sbnw8rRVBKe4JwVT7A32sHXGJ9pVc0j72Cxh1H-fPQ@mail.gmail.com>
To: David Muir <davidkmuir@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)

Whoops, I linked to the wrong gist...  Here's the proper one:

https://gist.github.com/1955338

On Thu, Mar 1, 2012 at 11:32 PM, David Muir <davidkmuir@gmail.com> wrote:
> I can't comment on the internal implementation, but I like the use of
> the casting syntax. It's not as pretty, but make the intent clear, and
> there's not BC issues with class names.
>
> David
>
> 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
>> topic. =A0But I whipped together a quick POC patch to implement scalar
>> type casting for function parameters. =A0Let me describe it:
>>
>> Patch: https://gist.github.com/1947259
>>
>> Example:
>>
>> function foo( (int) $bar ) {
>> =A0 =A0 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()); // E_RECOVERABLE_ERROR
>>
>> Right now, I only implemented the checks for (int), but I add the
>> 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? =A0Well, there are really three main reasons.
>> =A0First off, to indicate that a cast may happen. =A0Second, to prevent
>> needing new tokens (and hence reserved words). =A0And third to provide a
>> distinction between a string class type hint and a string scalar type
>> hint.
>>
>> Why did I only implement (int)? =A0Well, because I just wanted to build
>> a quick dirty POC that can be executed to see the semantics of
>> operation. =A0There are issues with it now, so rather than doing all the
>> work to re-do it later, I just implemented int...
>>
>> Why implement (object)? =A0Because right now, there's no way to say you
>> want to accept a generic object without caring about type. =A0So the
>> (object) cast/hint would then provide that ability to accept a generic
>> object.
>>
>> Why not implement (resource)? =A0Because that would require a new parser
>> token, as it's not available now...
>>
>> How does the casting work? =A0Right now, it's using a copy of the same
>> rules that internal functions use with zend_parse_parameters. =A0That
>> way, it brings the operating semantics of internal functions and
>> 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
>> non-referenced calls. =A0So that means the cast effects the original
>> zval AND the argument. =A0Which is a no-go for a production patch. =A0So
>> that means that the cast logic would need to be put after the zval
>> split. =A0But we'd still want the checks first, so it's not too
>> difficult to segregate, just requires deeper changes. =A0It's not
>> difficult (that I can see yet), just more work... =A0Example of the
>> problem:
>>
>> # sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =3D
>> "1"; foo($a); var_dump($a);'
>> int(1)
>> int(1)
>>
>> 2. =A0Right now, the zend_aprse_arg_impl (
>> http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
>> that's used by internal functions is defined as static. =A0So we'd be
>> copying a lot of the code back and forth. =A0In the production patch,
>> I'd also want to re-factor that out a bit into either functions or
>> macros to handle the type conversion and casting in both places. =A0That
>> way, both systems would behave identical (or as close as possible).
>>
>>
>> So, with that said, what do you think? =A0Is this something worth
>> pursuing? =A0Are there any fundamental issues that I'm missing? =A0What
>> else would we need to cover in a production patch and RFC?
>>
>> Thanks,
>>
>> Anthony
>>
>