I should point out that returning false on param parsing failure on the
language level is one thing (not to mention it's not ok to do that in the
first place by my taste), but forcing that behavior on the user-land level
is kind'a too much.
Consider how the code will become much more complicated - now you have to
not only to check what you pass to the functions, but you have to check
what it returns every single time (do I have to mention that false can be
never returned by the function at all except when the param parsing fails?).
What is consistent and exists on the internal language layer
not necessarily good for the user-land. I'm kind'a surprised no one thought
of that.
As I said I can live with the throwing notices and warnings (and not
E_RECOVERABLE_ERROR as I personally wanted), but returning false even not
trying to run the function is just a bad idea all over the place.
2012/3/12 Anthony Ferrara <ircmax...@gmail.com>
> Ok, so it looks like we've had some decent conversation, but it has
> started to tail off a bit. I'd normally draft an RFC at this point,
> but it seems there's still some contention on how exactly the
> implementation should work.
>
> Personally, if we're going to go for any form of strict checking
> (meaning not blind-conversion), I will not support these hint rules
> diverging from zend_parse_parameters (internal functions). It just
> creates a new layer of inconvenience and confusion for not a whole lot
> of gain. When I say divergence from ZPP, I'm talking about the same
> behavior when ZPP returns SUCCESS, and a E_RECOVERABLE_ERROR when ZPP
> returns FAILURE...
>
> Now, with that said, I'd be all for making sane changes to ZPP to
> bring both inline with a common goal. Think that passing "1abc" to an
> int type hinted parameter (which currently raises a notice) is
> unacceptable? Then my opinion is that it should be tightened in both
> places at the same time. But they should stay connected as closely as
> possible for consistency...
>
> So, with that said, let me ask this question: What needs to change
> from the current POC before it can be formalized into an RFC? Do we
> need to tighten the conversions? Or are they OK as-is?
>
> Thoughts?
>
> Anthony
>
> On Sat, Mar 10, 2012 at 2:45 AM, Tjerk Meesters
> <tjerk.meest...@gmail.com> wrote:
> >
> > On 9 Mar, 2012, at 11:20 PM, Lazare Inepologlou <linep...@gmail.com>
> wrote:
> >
> >> Type casting combined with passing by reference is problematic in many
> >> ways. Just an example:
> >>
> >> fuction foo( string & $buffer) { ... }
> >> foo( $my_buffer );
> >>
> >> Here, $my_buffer has just been declared, so it is null. Should this be
> an
> >> error? I don't know! So, I think that that passing by reference should
> not
> >> be (immediately) supported.
> >>
> >
> > Strictly speaking, if you add a type to a referenced variable in that
> way it's only logical that you expect it to have a proper value when the
> function is called. After all, it's not an output type declaration :)
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
