On 13 Jul 2014, at 16:01, Zeev Suraski <z...@zend.com> wrote:

>> From my point of view, if the type annotations are doing implicit cast
>> (with or
>> without E_NOTICE/E_STRICT warning), they should behave exactly the same
>> than an explicit cast. If it behaves differently, I'll be really difficult
>> for a
>> developer to guess what will be the PHP behaviour with this new syntax.
> 
> Coming to think of it, this is probably the cleanest and most productive
> approach.  +1.

If we interpret that to mean just casting everything with no error cases, but 
E_NOTICE on some, then it is one of the three main proposals suggested for 
scalar type hinting:

1. Casting type hints
2. Strict type hints
3. Scalar type hinting with casts

(There are others, but I won’t talk about them)

I’m not of the opinion that the first option, where we just cast and never 
error, is ideal. It does ensure the values are of the correct type when they 
get to you, so it keeps PHP’s type juggling, but it is unlikely to catch bugs 
where the wrong value has been passed.

The second option, while appealing to some, goes completely against PHP’s type 
juggling. You’d have to manually cast everything yourself. As I understand it, 
this is essentially what Hack does, but PHP is not Hack and I don’t really 
think this is a good idea.

A fourth option would be to allow both by using different syntaxes for casting 
and strict, but I don’t think we should add two different ways because we can’t 
agree; we should do it just one way.

The final option, which this RFC proposes, is something of a compromise between 
the two proposals. I think it’s sufficiently strict to prevent bugs, and the 
parameter will be the right type, but it does not stop type-juggling.

Nikita wrote about the subject of the different approaches here in 2012: 
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html

However, I don’t propose “strict weak” typing, I propose this RFC.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to