Hi, Anthony
At first, thanks for your great work!
As I have to learn C and C++ from scratch it was quite a good help to have
someone like you pushing it forwards.
I like having the casting exactly in the definition of the function, even
if it just saves the 6 characters. You have all information in one place.
As you added array as type-cast ... is it now possible to put an instance
of ArrayIterator in there? Would the following code work out?
function foo((array) $a) { /* do something */ }
$bar = new ArrayIterator( array() );
foo($bar);
I'd pretty much like the idea to break the script if you pass a value that
would produce a E_WARNING in type-casting.
But here comes another question for type-casting ... is it meant (as php
supports type-juggling) to get something of nearly every value (like to
parse "foo" to an integer) or is it more meant like getting a value in
another type and you should know that it is compatible with this other type
(like only parsing "1" to an integer)?
If it's meant like the last, then I'd may look for another way to implement
this ... Then this code would may make sense (not really to me, but it
would work out) ...
function foo((int) $i) { /* do something */ }
foo( (int)"foo" ); // would work as type-casting tries to get the last bit
of valuable data out of the passed information
foo( "foo" ); // would fail because the passed value is incompatible with
an integer
foo( "10 foo" ); // I personally would like to let it fail ... But maybe we
should let it be parsed to (int)10 silently ...
foo( "1" ); // would work
As far as I know, this is the behavior used for internal function calls -
isn't it?
I hope you'll get the difference ;)
I don't know if this difference actually applies to type-juggling and
type-casting ... As I understand type-juggling is just transforming it into
the other type if it can get something useful out of the content (like
parsing "1" or "10 foo" to an integer but not "foo"). Maybe type-juggling
uses the same functionality as weak-comparison ...
Bye
Simon
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
>
>
