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 <davidkm...@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. 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 >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
