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?
[deleted]
Comparing the PHP 7 and Hack Type Systems
11–20 of 38 posts
Re: Comparing the PHP 7 and Hack Type Systems
#12I believe that 1 == true as much as the next nerd, but still, this line: declare(strict_types=1) is that not a bit ironic?
I think so, too. I know, I am just hating, but to me it seems like they just can not quite change their culture. Even if they implement something clean and elegant like strong typing their hacky past finds a way to slip in. Nevertheless, congrats to them, they actually deliver.
[deleted]
Re: Comparing the PHP 7 and Hack Type Systems
#13Earlier quoted context omitted.
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.
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?
Hmm, perhaps the opcode has the wrong line number attached to it. A bug report could be filed for that, probably a trivial fix.
Re: Comparing the PHP 7 and Hack Type Systems
#14> 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.
Re: Comparing the PHP 7 and Hack Type Systems
#15I believe that 1 == true as much as the next nerd, but still, this line: declare(strict_types=1) is that not a bit ironic?
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);
Re: Comparing the PHP 7 and Hack Type Systems
#16It'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…
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.
Re: Comparing the PHP 7 and Hack Type Systems
#17Earlier quoted context omitted.
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.
Which Hack does too (static checking). What he describes (logging) can be enabled as an alternative to that. Maybe you should try it?
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).
Re: Comparing the PHP 7 and Hack Type Systems
#18I believe that 1 == true as much as the next nerd, but still, this line: declare(strict_types=1) is that not a bit ironic?
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.
> saving 5 chars from something that'll be typed very frequently is probably worth it.
This mindset is something that I've personally seen uniquely permeate every layer of the PHP community, more than anywhere else. I'm honestly curious, what makes communities seem to value things like typing less characters over clarity and correctness? The most important thing to me is reducing the amount of mental state needed for a human to read any line of code.
Re: Comparing the PHP 7 and Hack Type Systems
#19Fatal 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 ba…
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.
I disagree - even if hack was reporting the correct line number it's only half the story, and is objectively worse for fixing the error.
Re: Comparing the PHP 7 and Hack Type Systems
#20It'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…
Even without static types tools like PHPStorm have offered that type of analysis and error reporting.