On Mon, Jul 14, 2014 at 11:16 PM, Park Framework
<park.framew...@gmail.com> wrote:
> 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
>> >
>> >
>>
A massive +1 for this approach. I had the same thought the other day
after watching this thread aganoise between "to cast, or not to cast."
Trying to make some types automatically cast and some just assert
(like some do already) is a road that leads to pain and suffering.
Trying to make them all just assert is not "the PHP way".
Trying to make them all cast (thus changing the exist array assertion
into a cast action) would be bizarre and strange.
So what is left? Two syntaxes, so cast and assert can both be taken care of.
foo(int $num) - for strict type compliance
This HAS to be an int and an array. Nothing else will fly.
bar((int) $num) - converted to type
This has to be anything that could be turned into an int, which to be
fair is basically anything, and anything that can be turned into an
array.
foo(123); // OK
foo("123"); // Not OK
foo("123a"); // Really not OK
bar(123); // OK
bar("123"); // Casts to 123
bar("123a"); // Casts to 123
bar(" 123a"); // Casts to 123
Even if you guys would like to suggest that foo("123"); should be ok
because $_GET variables, I would sill strongly urge people to consider
the "type assertions dont cast" approach, and add easy casting for
"assert and cast" functionality.
It's the most consistent and easy to explain approach, even if it does
lead to the occasional developer saying "Oh, my unfiltered $_GET input
is a string instead of an int. How do I... ahh I just use foo((int)
$_GET['whatever']);
Not an issue in 2014 I believe.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
