Scalar type hints in PHP trunk
Trackbacks
More on scalar type hints in PHp trunk
Some time ago I wrote an article about the implementation of type hints for non-object types for PHP. Meanwhile many things happened and that implementation was replaced by a different one. Readers of my previous post might know that I have doubts about t
Some time ago I wrote an article about the implementation of type hints for non-object types for PHP. Meanwhile many things happened and that implementation was replaced by a different one. Readers of my previous post might know that I have doubts about t
Weblog: Johannes Schlüter
Tracked: Nov 22, 23:15
Tracked: Nov 22, 23:15
PHP 5.4 Alpha 1
Recently PHP 5.4.0 Alpha 1 was released and the PHP development team is asking every PHP user to test it. In this blog I have some articles about upcoming features in that version. Now is a good time to test 5.4 in combination with your applications spot
Recently PHP 5.4.0 Alpha 1 was released and the PHP development team is asking every PHP user to test it. In this blog I have some articles about upcoming features in that version. Now is a good time to test 5.4 in combination with your applications spot
Weblog: Johannes Schlüter
Tracked: Jul 02, 02:24
Tracked: Jul 02, 02:24



Sunday, August 8. 2010 at 00:53 (Link) (Reply)
There is a proposal floating about to convert them to coercing-type hints or casting type hints (vis, passing "5" to int $a would work but "5.3" would not), and it seems like the best way forward for now. If that doesn't happen then we've just turned PHP into a strongly typed language in a backdoor manner, which is sad.
Sunday, August 8. 2010 at 06:57 (Link) (Reply)
http://wiki.php.net/rfc/typechecking
I refuse to call the strict typing "hinting" .. its not hinting, thats a euphemism.
Sunday, August 8. 2010 at 08:44 (Reply)
And now we will get bloated code with tons of explicit casting to satisfy such interfaces.
Why just wouldn't make php itself strongly typed then?
Sunday, August 8. 2010 at 09:14 (Reply)
You post demonstrates just a couple of problems with it, I'm sure there will be myriads more as soon as people start using it. If somebody needs Java, he knows where to find it...
Sunday, August 8. 2010 at 13:25 (Reply)
Personally I think everybody would have been much happier with just a 'scalar' typehint:
function foo(Scalar $bar) { ... }
Sunday, August 8. 2010 at 13:27 (Reply)
Sunday, August 8. 2010 at 16:59 (Reply)
1. Type casting via "hint"... This could have its own identifier, or be the default action. So:
[geshi lang=php]function foo(cast int $foo = 4) {[/geshi]
Would always have an int as the value for $foo (If you pass '3.5', it'll be parsed with the type cast (int)... With this, I would implement a __castAs magic method (similar to __toString, but accepts any type as a parameter, and it's up to the class to determine if it can cast)...
2. The current implementation, but with the addition of a strict keyword:
[geshi lang=php]function foo (strict int $i = 4) {[/geshi]
which would error (exception preferably) if you pass '4'...
3. The current implementation would work IF they added function/method overloading. So instead of
[geshi lang=php]parseInt(int $foo);
parseFloat(float $foo);
...[/geshi]
you'd be able to do :
[geshi lang=php]parse(int $i) {}
parse(float $f) {}
etc...[/geshi]
I'm not sure this is great (since it takes some of the flexibility of the dynamically typed nature of php.
I'm not against strict typing in php. There are a few use-cases where it may make sense. But, I think it would be far more useful to use casting in its place...
Wednesday, August 11. 2010 at 00:34 (Reply)
What I want, and I think the most other too, is just plain simple:
function test(int $number) {
return $number;
}
test(1); // 1
test(1.0); // Catchable fatal error
test("1"); // 1
test("blah"); // Catchable fatal error
Saturday, August 14. 2010 at 17:10 (Reply)
On the other hand, I could live happily without function overloads.
Sunday, August 8. 2010 at 17:46 (Link) (Reply)
Sunday, August 8. 2010 at 18:45 (Reply)
That error should be given if it was something like parse_int() and a float was given.
Tuesday, August 10. 2010 at 01:25 (Link) (Reply)
So where's the downside? That developers might actually create strict APIs? Sorry - they're already doing that. Leaving type conversion to PHP and pretending you can create generalised code for every eventual input that will be consistent is a fairy tale. One developer's PHP flexibility is another's error prone waste of space that needs validation
Tuesday, August 10. 2010 at 02:10 (Link) (Reply)
Strict typing in PHP is tantamount to saying "please don't use my library".
Tuesday, August 10. 2010 at 09:43 (Reply)
By erecting typechecking barrier you are just saying "I'm too precious to live in the dirty world of dynamic language, please give me only filtered data or I'll refuse to work". That's the opposite of what good API should do - "produce strictly, accept liberally". The code that deals with dirtyness of dynamic language should be pushed into the library, not out to the user - and that's exactly what strict typing is doing, laying it all onto the user.
Even worse, it does it in RUNTIME. Which means when - note, I'm not saying "if", I'm saying "when" - you forget one check before calling your API, your API would bomb out on you in runtime, and you have absolutely no means to work around it or prevent it - with (int) you'd at least get clean 0, integer as good as any other, with strict typing you get an error, goodbye.
Strict typing in PHP will be worst of both worlds - as annoying as Java yet without added safety of static type checking. You'd be better off using actual Java (or another strictly typed compiled language).
Wednesday, August 11. 2010 at 10:36 (Link) (Reply)
Wednesday, August 11. 2010 at 17:09 (Link) (Reply)
That means that I, interacting with your library, suddenly have to keep track of the type of all of my variables. My code now has to be strictly typed so that it can interact with yours. It is now no longer optional. That means any code interacting with mine has to now care about strict types. And so on. It is disgustingly viral.
There are plenty of strictly typed languages out there. PHP is not one of them, nor should it be, certainly not due to a late-night sneak attack patch. There is nothing optional about it.
Wednesday, August 11. 2010 at 19:01 (Reply)
Are you for removing is_int() from the language too? Because people who insist on checking types in their code are probably using it right now anyway.
Monday, August 16. 2010 at 22:53 (Reply)
"1" and 1 are NOT functionally equivalent. PHP simply provides implicit runtime casting.
However, type checking should only be used in situations where the scaler type would change the behavior. In most cases a "numeric" or "scaler" type would suffice.
e.g.
function strContainsChar($str, $char)
{
echo strpos($str, $char)!==false?"{$str} does not contain {$char}\n":"{$str} contains {$char}\n";
}
strContainsChar(3, 3);
strContainsChar(3, "3");
strContainsChar("3", 3);
strContainsChar("3", "3");
outputs:
3 contains 3
3 does not contain 3
3 contains 3
3 does not contain 3
The simplest solution is to cast all parameters...
function strContainsChar($str, $char)
{
echo strpos((string)$str, (string)$char)!==false?"{$str} contains {$char}\n":"{$str} does not contain {$char}\n";
}
strContainsChar(3.0, 3.0);
strContainsChar(3.0, "3.0");
strContainsChar("3.0", 3.0);
strContainsChar("3.0", "3.0");
outputs:
3 contains 3
3 does not contain 3.0
3.0 contains 3
3.0 contains 3.0
We still get unexpected behavior even with type casting. This is a clear case for type checking.
Tuesday, August 24. 2010 at 20:52 (Link) (Reply)
If someone dislike typing strict, he can just ignore and not use these "hintings"
Wednesday, August 3. 2011 at 10:06 (Reply)
One more example where PHP automatically cast types:
$i = PHP_INT_MAX;
echo gettype($i) . PHP_EOL; // integer
$i++;
echo gettype($i) . PHP_EOL; // double
That means if type hinting, than the type should be casted automatically
and the function/method knows what type it has.
I like the way of the cast/strict keywords but if not present cast should the default. The question here is how often a "string" keyword makes sense and needs to be implemented with 2 new reserved words.