Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58453
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
Received-SPF: pass (google.com: domain of davidkmuir@gmail.com designates 10.68.233.67 as permitted sender) client-ip=10.68.233.67;
Message-ID: <4F504D4D.6010806@gmail.com>
Date: Fri, 02 Mar 2012 15:32:13 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: internals@lists.php.net
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
In-Reply-To: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of
 Concept
From: davidkmuir@gmail.com (David Muir)

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.  But I whipped together a quick POC patch to implement scalar
> 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()); // 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?  Well, there are really three main reasons.
>  First off, to indicate that a cast may happen.  Second, to prevent
> needing new tokens (and hence reserved words).  And third to provide a
> distinction between a string class type hint and a string scalar type
> hint.
>
> Why did I only implement (int)?  Well, because I just wanted to build
> a quick dirty POC that can be executed to see the semantics of
> operation.  There are issues with it now, so rather than doing all the
> work to re-do it later, I just implemented int...
>
> Why implement (object)?  Because right now, there's no way to say you
> want to accept a generic object without caring about type.  So the
> (object) cast/hint would then provide that ability to accept a generic
> object.
>
> Why not implement (resource)?  Because that would require a new parser
> token, as it's not available now...
>
> How does the casting work?  Right now, it's using a copy of the same
> rules that internal functions use with zend_parse_parameters.  That
> 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.  So that means the cast effects the original
> zval AND the argument.  Which is a no-go for a production patch.  So
> that means that the cast logic would need to be put after the zval
> split.  But we'd still want the checks first, so it's not too
> difficult to segregate, just requires deeper changes.  It's not
> 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 =
> "1"; foo($a); var_dump($a);'
> int(1)
> int(1)
>
> 2.  Right 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.  So we'd be
> copying a lot of the code back and forth.  In 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.  That
> way, both systems would behave identical (or as close as possible).
>
>
> So, with that said, what do you think?  Is this something worth
> pursuing?  Are there any fundamental issues that I'm missing?  What
> else would we need to cover in a production patch and RFC?
>
> Thanks,
>
> Anthony
>