
Comparing the PHP 7 and Hack Type Systems - jazzdan
http://www.dmiller.io/blog/2015/4/26/comparing-the-php7-and-hack-type-systems
======
Vendan

      Fatal error: Argument 1 passed to myLog() must be of the type string, integer given, called in /home/vagrant/basic/main.php on line 9 and defined in /home/vagrant/basic/main.php on line 4
    

"HHVM says the error occurred on line 6 where PHP says it occurred on line 9.
I prefer HHVM's approach here as it shows us where we called the function with
the bad data, not where the function is defined that we are calling with bad
data."

Hrm, PHP is telling you both line 4 and line 9, as where the function is
defined and where it's being called with bad data, which is quite nice. In
comparison, HHVM is saying line 6, which is a closing brace for the myLog
function. In my books, PHP's approach is way way better then HHVM's

~~~
Bahamut
It's hard to say what is better - oftentimes when you see a large stack trace
for an error, it can be difficult to determine where the offending line is,
especially on first glance. Personally, I think I agree with the author, but
PHP 7 does look to give more information, which can be better in some
situations.

~~~
jontro
However in this case line 6 is not the problem in any way (as the grandparent
is saying). Looks like a bug in the error reporting?

~~~
TazeTSchnitzel
Hmm, perhaps the opcode has the wrong line number attached to it. A bug report
could be filed for that, probably a trivial fix.

------
jwatzman
It's worth pulling out what I think is the most fundamental difference between
the two type systems, from the end of the article:

 _After writing a couple small programs in Hack I 've realized that it's not
types themselves that make writing Hack enjoyable: it's the tight feedback
loop Hack creates between the machine and myself. Integrating the Hack type
checker into my editor means that my entire codebase is analyzed in a split
second as soon as I save a file. This immediately surfaces any dumb, or subtle
mistakes I made. I find myself writing code fearlessly: when I forget what a
function returns, I just write code that calls it with what I think it
returns. If I'm wrong, the type checker will tell me immediately. I can fix it
quickly, and move on._

Hack's type system is static -- it's enforced by a static analysis tool that
instantly reports errors in all of your code. PHP can only report errors that
it actually encounters at runtime. Along with the "fearlessness" above, it
also means that you might miss you forgot to check for a null in an error
case... until it explodes at runtime in production. Hack's static type system
can mechanically check for all of these immediately.

~~~
TazeTSchnitzel
The difference isn't between the systems, it's a difference in tooling, in
that Hack comes with its own type checker. Part of the motivation for PHP 7's
expanded type hinting support was to enable better static analysis tools. I
expect we'll see something similar to Hack's type checker for PHP 7 in not too
long. Actually, some IDEs already check types, I think.

Of course, a tool for PHP 7 can only go so far, because PHP 7's type hints
aren't sufficient to cover everything, unlike Hack which has things like
nullable support.

------
aaronharnly
I believe that 1 == true as much as the next nerd, but still, this line:

    
    
      declare(strict_types=1)
    

is that not a bit ironic?

~~~
TazeTSchnitzel
Yes, and as the person who came up with that, I was well aware of the irony.
It was originally this:

    
    
      declare(strict_typehints=TRUE);
    

However, I changed it to the form that you see there because it was shorter. I
felt that in the grand scheme of things it's not very important: declare()
isn't a function, it's a language construct, and saving 5 chars from something
that'll be typed very frequently is probably worth it.

~~~
ars
I sort of wish you had done:

    
    
      declare(types=strict);
    

instead. That way other options can be added in the future.

~~~
giaour
I believe there was some discussion of using the same strict declaration as
javascript ('use "strict";'), but there's already an "easter egg" in PHP that
causes your program to exit and prints out something like "I think you're
using the wrong language."

For some reason, this Easter egg was deemed too important to displace with an
actual language construct.

~~~
TazeTSchnitzel
Well, there's also the fact that something that changes the language behaviour
really should be a pragma and not a magic import statement.

------
ejcx
I really like writing hack and haven't tried PHP7. It makes a huge difference
having types. If you have a function

    
    
        function dowork(@?string $w)
    

You can allow execution to continue but still log the error. It's made me
aware of all sorts of edge case bugs that I never would have been able to find
before.

XHP has allowed me to do the same, by forcing me to write well formed html and
I love it

~~~
mirashii
You should seriously consider trying a language with a more complete and
robust type system that is checked at compile time. If you like the fact that
these kind of corner cases can be logged, imagine if you can find them before
you ever hit them at compile time.

~~~
coldtea
Which Hack does too (static checking). What he describes (logging) can be
enabled as an alternative to that.

Maybe you should try it?

~~~
mirashii
If you're logging, the only good reason to do so instead of fixing errors
which your type checker found at compile time is if you're mixing PHP and
Hack, which is where you'd get type errors that couldn't be determined at
compile time. I'm suggesting using a language with an environment that is more
completely statically checked (and preferably also has a more complete type
system, something functional perhaps).

------
TazeTSchnitzel
> HHVM calls this a "catachable" fatal error. This is interesting as in the
> RFC the error shown actually matches HHVM's error.

It _was_ a "catchable" fatal error (i.e. E_RECOVERABLE_ERROR) in PHP 5.x for
typehints. But PHP 7 is changing it to be an Exception instead, and for some
reason it currently produces an inaccurate error message in the master branch
- it should say "Uncaught exception" (which it is), but that's not been fixed
yet. Trunk builds aren't ready for production use, etc.

------
allan_s
For nullable types, there's a plan/rfc to have them too

[https://github.com/php/php-src/pull/1045](https://github.com/php/php-
src/pull/1045)
[https://wiki.php.net/rfc/nullable_types](https://wiki.php.net/rfc/nullable_types)

not for 7.0 but hopefully for 7.1

