Maybe we should make two different syntax?
fun(int $num, array $list) - for strict type compliance
fun((int) $num, (array) $list) - converted to type
It will be very obvious, and without magic.
2014-07-14 23:23 GMT+03:00 Chuck Reeves <chuck.ree...@gmail.com>:
> I am new to the list and internals so my question might be obvious to
> others: Why even cast the variable? When I look at a function and see:
>
>
> function myFunc(array $someData)
> {
> //some processing
> }
>
> I understand that myFunc requires an array passed in. If I try to call
> myFunc like so:
>
> myFunc('foobar');
>
> I get a fatal error stating that I did not pass in an array. If I try with
> stdClass:
>
> myFunc(new \stdClass());
>
> I will get the same error however If I cast the object before passing in
> like so:
>
> myFunc((array) new \stdClass());
>
> It works just fine. The benefit of having the hint tells whom ever is
> going to consume the function that the parameter needs to be casted to the
> scalar type.
>
> If I have this:
>
> function addTwoValues(int $valueOne, int $valueTwo);
>
> It is clear that i need to make sure I'm using int's. If I try to call
> that function with any other type, I would like to get the error instead of
> some kind of auto-magical cast into something that could product strange
> results.
>
> I think the benefit is in having the hint with excluding the cast of the
> value. Let the user cast the value to what the function requires. IMHO
> Allow the author of the function to dictate what is needed to execute.
>
>
> On Mon, Jul 14, 2014 at 3:59 PM, Andrea Faulds <a...@ajf.me> wrote:
>
> >
> > On 14 Jul 2014, at 20:53, Rowan Collins <rowan.coll...@gmail.com> wrote:
> >
> > > The debate in this thread basically comes down to us each wanting our
> > favourite from that list of features to have the privilege of dedicated
> > syntax in function signatures.
> >
> > That’s why this RFC is supposed to be a best-compromise solution between
> > strict and just casting. The hope is to appease both sides and provide
> the
> > most workable solution, really. It’s also the style that I, myself, like
> > best, because it’s strict enough to catch bugs (I like that), and it
> keeps
> > PHP a type-shifting language (I like that too).
> >
> > --
> > Andrea Faulds
> > http://ajf.me/
> >
> >
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
