On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> On 02/20/2015 09:39 AM, Anthony Ferrara wrote:
>> I think if anything, the appearance of Hack (and its adoption) show
>> that people want static typing, at least to some level...
>
> To be perfectly transparent here though, you should mention that your
> proposed RFC goes well beyond the strict typing that is in Hack because
> in Hack the internal API is largely untyped while your proposal is to
> default the entire internal API to strict types in strict mode. Also, in
> Hack there is a distinction between the off-line hh_client type-checker
> and the runtime.
This distinction is going away pretty soon. The typechecker is an integral part
of Hack, and you shouldn't be able to ignore its errors. The runtime will soon
consider them fatal errors too. If your code doesn't pass the hh_client
typechecker, then its behavior when run on HHVM is completely undefined.
> Hack examples all using <?hh // strict
>
> echo number_format('1000');
> echo htmlspecialchars(1000);
> echo md5(1000);
>
> These are all fine both as far as the type-checker is concerned as well
> as the runtime, of course, but they are runtime fatals in your proposed RFC.\
And they should be errors in Hack too. The reason they aren't are to ease
transitions from PHP to Hack. I'd expect them to be more strongly typed
eventually.
> And if you only go by the runtime and ignore the out-of-band type
> checker there are almost no strictness rules applied to the internal API
> in Hack.
>
> eg. explode(0, 1000);
>
> Here the hh_client type checker will complain that it is expecting
> strings, but the runtime will run it nicely.
>
> So when you say, and as I have heard other people say, that people want
> Hack-like strict typing, you have to be a bit careful about what is
> meant by that. Even in the cases where the internal API is typed in
> Hack, it is still not a runtime fatal if they are called with the wrong
> types.
See above -- relying on (or even really thinking about) this distinction is
relying on implementation details which are going to change.
Josh
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
