Live data from Hacker News

Comparing the PHP 7 and Hack Type Systems

dmiller.io

31–38 of 38 posts

Re: Comparing the PHP 7 and Hack Type Systems

#31

Earlier quoted context omitted.

i quite like this concept too, but both are still better than Hack's Strict what?

Hack's is a comment, not a proper pragma, too.

Yeah that's kinda sucky too. I assume it's because they also support their "strict" mode with regular php files?

Re: Comparing the PHP 7 and Hack Type Systems

#32
post #3
post #2

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 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.

Part of the point is that the article is just dead wrong. "I prefer HHVM's approach here as it shows us where we called the function with the bad data". HHVM says line 6, which is the end of the function, not where the function was called. In fact, they go on to state "not where the function is defined that we are calling with bad data." while still having said "PHP says it occurred on line 9" But line 9 IS where the function was called with bad data. The article misinterpreted the 2 errors...

Re: Comparing the PHP 7 and Hack Type Systems

#33

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?

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.

Well, there are non-ironic alternatives:

    declare(strict_typehints=TRUE); // not ironic, not short
    declare(strict_types=1); // ironic, short
    declare(strict=true); // not ironic, even shorter
JS has one strict mode, this could've been an opportunity to introduce an umbrella mode for strict coding in general.

Also the declare syntax could've been augmented to support passing implicit boolean parameters without setting a value:

    declare(strict); // oh yeah.
So... you know. Not that it matters what you call it, but choosing ugly (and ironic) over pretty (and sane) shouldn't be taken so lightly.

Re: Comparing the PHP 7 and Hack Type Systems

#34
post #24

Earlier quoted context omitted.

> 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…

Because PHP is for really fast development, and not for slow movers who actually think a lot. That's what I sense after joining a company using PHP. The language itself feels like a bag of features copied over from top contenders from the TIOBE index. You can see the fastness in the core of the language design. After all, you use PHP to perform MySQL queries in the middle of HTML tags. If you want to do this, you kno…

We program so hard we don't have time to think. Or type. At least not with as many characters as a sane person would.

Re: Comparing the PHP 7 and Hack Type Systems

#35
post #21

Earlier quoted context omitted.

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.

I sort of wish you had done: declare(types=strict); instead. That way other options can be added in the future.

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.

Re: Comparing the PHP 7 and Hack Type Systems

#37
post #24

Earlier quoted context omitted.

Because PHP is for really fast development, and not for slow movers who actually think a lot. That's what I sense after joining a company using PHP. The language itself feels like a bag of features copied over from top contenders from the TIOBE index. You can see the fastness in the core of the language design. After all, you use PHP to perform MySQL queries in the middle of HTML tags. If you want to do this, you kno…

Just because you can do something doesn't mean you should The sort of approach you're describing is not suggested or used by anyone with half a clue what they're doing.

Indeed, no one with half a clue what they're doing uses PHP.

Re: Comparing the PHP 7 and Hack Type Systems

#38
post #35
post #21

Earlier quoted context omitted.

I sort of wish you had done: declare(types=strict); instead. That way other options can be added in the future.

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.

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