John,
> The reason you have to validate the input type in this case is because even
> though it is a reference, we don't ACTALLY know that it isn't supposed to
> contain an input (even though that would be against all sane rules most of
> the time).
Well, we don't know, but I'd argue do we really care? If they passed
a different type that's going to get casted away, that's their
problem. They passed it to the hint. Now, if you're talking about
object cast sementics, that raises a whole different ballgame. That's
something that we should consider...
> I'm not attached to this idea at all, but I thought I'd throw it out and see
> if anyone can think of a problem with it; what if we added extra out and
> inout hints for references?
>
> // So this would give no error at all. Parameter is anticipated to be for
> output. Just silently change the type and don't warn on anything.
> fuction foo( out string & $buffer) { ... } foo( $my_buffer );
>
> // This WOULD give an error, because the parameter is also an input parameter:
> fuction foo( inout string & $buffer = NULL) { ... } foo( $my_buffer );
Why would NULL give an error under any circumstance? You defaulted it
to null. So why should passing a NULL parameter in its place be any
different than not passing a first argument? In fact, erroring on
that would greatly reduce utility, since what if I wanted to set the
2nd parameter only? I can no longer pass NULL (even though it's a
valid default), and have to change the first parameter. Big
regression if you ask me...
> // In any case no errors on these:
> fuction foo( inout string & $buffer = NULL) { ... } foo( (string)$my_buffer );
> fuction foo( string & $buffer = NULL) { ... } foo( (string)$my_buffer );
Actually, these SHOULD cause errors (and do). Because they will not
do what you expect. The cast causes a *temporary* variable to be
created in opcode. And you can't pass a temporary variable by
reference: http://codepad.viper-7.com/wLBSkS
> If we assumed that all references were out unless stated otherwise we could
> avoid reserving an "out" keyword, and only add "inout", which is unlikely to
> conflict with stuff.
I still fail to see the purpose. Both will cause a cast (since the
value required on the other end needs to be initialized to the proper
type). The only difference is that one throws an error on invalid
cast, and the other doesn't. Seems to be to just be un-necessary
added complexity (but feel free to convince me otherwise, I love to be
convinced wrong)...
> Like I said, no attachment to this at all. My gut tells me I may have missed
> something really stupid here. Just brainstorming.
Oh absolutely. And brainstoring is good!
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
