[RFC] Scalar Type Hinting With Casts (re-opening)

Maybe we should make two different syntax?

fun(int $num, array $list) - for strict type compliance
fun((int) $num, (array) $list) - converted to type

+1

Don't forget to note that we will still retain the current syntax:

fun($num, $list) - arguments passed as is, not type checking/juggling

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

On Mon, Jul 14, 2014 at 11:16 PM, Park Framework
park.framework@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.reeves@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.

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/

--

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.