> > 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. >
Personally, I think it saves much more characters (,,,in the documentation). And I think, that's enough. Nothing more is needed here. If we want to expand further on, I believe that the type casting system should be enhanced with custom casting functions. The other proposal that you've made fits perfectly here. Would you like to test them combined? Another point of expansion is to have something similar for object types. However, this requires first the introduction of custom casting rules for objects types as well. Maybe in the future. Great work. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/3 Anthony Ferrara <ircmax...@gmail.com> > 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 = (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 <adamj...@gmail.com> > wrote: > > On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara <ircmax...@gmail.com> > wrote: > >> > >> Well, there are a few questions about the implementation: > >> > >> 1. *Which* type casting rules should it follow? > >> > >> a. Regular cast rules (like $foo = (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. Where 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? Perhaps. So at that point, foo(array > >> $bar) would do a "strict" check, and foo((array) $bar) would attempt > >> to cast. But my question would be: what would attempt to cast mean? > >> Should it error out if you pass foo(1)? That's what the internal > >> function cast rules do. And to me that's more obvious than silently > >> converting it to foo(array(1))... > >> > >> 3. Should references be supported? My 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. And even more confusing implicit casts behave yet another > >> way ($a + $b). So to implement this, we'd need to be consistent with > >> one of them. Frankly, I would only want to add consistency to > >> internal function parameters, since the explicit cast is not useful > >> IMHO (it's identical to $bar = (int) $bar), at which point it's not > >> worth adding to save only that one line. But 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... That way, all function calls behave the same (as much > >> as I hate the concept of warnings on type hint failure)... So, 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? Well, this entire patch (up to this point) > >> wouldn't require one. it's only adding the casting functionality > >> (which is not implemented today), so no problem. Existing code would > >> still function fine. > >> > >> Thoughts? Should 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 = "1"; > >> var_dump(foo($a));' > >> int(1) > >> > >> # sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a = > >> "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 > found > > within the body of functions. I believe users will expect it to act the > same > > 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 > proposed > > hinting solutions and PHP's intrinsic typing qualities. Keeping things > close > > to the current modus operandus seems like it gives the proposal more > chance > > of becoming a reality. > > > > I would also suggest that array not be included, if only to limit the > scope > > of the current proposal and simplify the offering. It could always be > added > > 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 > scalar > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
