Critiquing Facebook's new PHP spec • Hacker News Board

Re: Critiquing Facebook's new PHP spec

#11

Post by rmrfrmrf » Thu, Jul 31, 2014, 6:03 PM UTC

webkike wrote: post #6

When I read the new PHP spec, I threw up in my mouth after I saw that empty("0") was a special case of empty that returned TRUE. I know that's how PHP normally works, but that doesn't really make my mouth taste any better.

EDIT: Brain fart; don't use this. See comments below.

Just use the following if you really want to account for strings containing the number 0.

    (!isset($var) || $var === false);

Note the triple equals sign.

Re: Critiquing Facebook's new PHP spec

#12

Post by leeoniya » Thu, Jul 31, 2014, 6:05 PM UTC

wvenable wrote: post #9

webkike wrote: post #6

When I read the new PHP spec, I threw up in my mouth after I saw that empty("0") was a special case of empty that returned TRUE. I know that's how PHP normally works, but that doesn't really make my mouth taste any better.

The thing you have to understand about PHP, is it's meant to easily work in a world where every value is in a string. You get strings from the browser, you get strings from the database, and strings from the file system. It was expected that these strings contain numbers and that you should be able to rationally use them as numbers without conversion. So "10" > "5" returns true in PHP where as that would be false in…

what threw me personally about empty() is that it doesn't invoke magic getters: "__get".

Re: Critiquing Facebook's new PHP spec

#13

Post by arenaninja » Thu, Jul 31, 2014, 6:08 PM UTC

wvenable wrote: post #10

pbiggar wrote: post #8

Earlier quoted context omitted.

No, but I believe they're excited by it (according to Facebook's post at least). I'd expect Zend to keep supporting RAII, but I doubt new implementations will - its a real drag on building better GCs, and that can be as much as half the performance of a program.

I think the language would really need more features, like using blocks from C#, to be effective without RAII. The finally clause was only just added in the last release. The spec, as it stands, is flawed. Any removal of RAII should be left to major version (e.g. PHP7). Since this spec is meant to represent the current state of PHP, it's completely incorrect in this area.

I think your latter point is part of my confusion. Is this a proposal for what PHP should be or what it currently is? I'm as excited as anyone for the upcoming jPHP but, array bug aside, breaking BC is huge in PHP. I've used the __destruct method plenty of times to automate DB changes without explicitly calling a function to save those changes

Re: Critiquing Facebook's new PHP spec

#14

Post by arenaninja » Thu, Jul 31, 2014, 6:12 PM UTC

rmrfrmrf wrote: post #11

webkike wrote: post #6

When I read the new PHP spec, I threw up in my mouth after I saw that empty("0") was a special case of empty that returned TRUE. I know that's how PHP normally works, but that doesn't really make my mouth taste any better.

EDIT: Brain fart; don't use this. See comments below. Just use the following if you really want to account for strings containing the number 0. (!isset($var) || $var === false); Note the triple equals sign.

This won't work. Both 0 (numeric) and '0' (string) == false, but never === false (because when you === you're checking that it's the same type).

If you expect a string '0', simply check strlen($str) > 0. If the value could be numeric, use a (string) cast.

Re: Critiquing Facebook's new PHP spec

#15

Post by wvenable » Thu, Jul 31, 2014, 6:13 PM UTC

rmrfrmrf wrote: post #11

webkike wrote: post #6

When I read the new PHP spec, I threw up in my mouth after I saw that empty("0") was a special case of empty that returned TRUE. I know that's how PHP normally works, but that doesn't really make my mouth taste any better.

EDIT: Brain fart; don't use this. See comments below. Just use the following if you really want to account for strings containing the number 0. (!isset($var) || $var === false); Note the triple equals sign.

If you really want to test for empty strings where $a is defined just use:

    if ($a == "") { ... }

Empty is merely the function equivalent of the not (!) operator. The semantics are exactly the same except for the handling of undefined variables. It's not something one should use except if you're expecting to deal with undefined variables.

Re: Critiquing Facebook's new PHP spec

#16

Post by wvenable » Thu, Jul 31, 2014, 6:16 PM UTC

leeoniya wrote: post #12

wvenable wrote: post #9

Earlier quoted context omitted.

The thing you have to understand about PHP, is it's meant to easily work in a world where every value is in a string. You get strings from the browser, you get strings from the database, and strings from the file system. It was expected that these strings contain numbers and that you should be able to rationally use them as numbers without conversion. So "10" > "5" returns true in PHP where as that would be false in…

what threw me personally about empty() is that it doesn't invoke magic getters: "__get".

That's not true, empty() will call __isset() first, and only if it returns true will it call __get().

This is because empty() is the compliment to the isset() function. There is no reason to use empty() over the not (!) operator unless there is the potential your property doesn't exist.

Re: Critiquing Facebook's new PHP spec

#17

Post by pbiggar » Thu, Jul 31, 2014, 6:22 PM UTC

wvenable wrote: post #10

pbiggar wrote: post #8

Earlier quoted context omitted.

No, but I believe they're excited by it (according to Facebook's post at least). I'd expect Zend to keep supporting RAII, but I doubt new implementations will - its a real drag on building better GCs, and that can be as much as half the performance of a program.

I think the language would really need more features, like using blocks from C#, to be effective without RAII. The finally clause was only just added in the last release. The spec, as it stands, is flawed. Any removal of RAII should be left to major version (e.g. PHP7). Since this spec is meant to represent the current state of PHP, it's completely incorrect in this area.

I disagree. They underspecified the language, so it still technically represents the current state of the Zend implementation of PHP.

(I take no position on RAII being useful or not, I don't write PHP for a living).

Re: Critiquing Facebook's new PHP spec

#18

Post by wvenable » Thu, Jul 31, 2014, 6:28 PM UTC

pbiggar wrote: post #17

wvenable wrote: post #10

Earlier quoted context omitted.

I think the language would really need more features, like using blocks from C#, to be effective without RAII. The finally clause was only just added in the last release. The spec, as it stands, is flawed. Any removal of RAII should be left to major version (e.g. PHP7). Since this spec is meant to represent the current state of PHP, it's completely incorrect in this area.

I disagree. They underspecified the language, so it still technically represents the current state of the Zend implementation of PHP. (I take no position on RAII being useful or not, I don't write PHP for a living).

It's in direct conflict with the PHP manual:

http://php.net/manual/en/language.oop5.decon.php#language.oo...

"PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++. The destructor method will be called as soon as there are no other references to a particular object, or in any order during the shutdown sequence."

It's very common to rely on this behavior to do cleanup as PHP did not have a finally clause (like C++) until recently.

Re: Critiquing Facebook's new PHP spec

#19

Post by pbiggar » Thu, Jul 31, 2014, 6:30 PM UTC

wvenable wrote: post #18

pbiggar wrote: post #17

Earlier quoted context omitted.

I disagree. They underspecified the language, so it still technically represents the current state of the Zend implementation of PHP. (I take no position on RAII being useful or not, I don't write PHP for a living).

It's in direct conflict with the PHP manual: http://php.net/manual/en/language.oop5.decon.php#language.oo... "PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++. The destructor method will be called as soon as there are no other references to a particular object, or in any order during the shutdown sequence." It's very common to rely on this behavior to do cleanup as…

I think we're talking at cross-purposes. I'm just saying that because it's underspecified, the Zend engine can be both accurate to what's in the PHP manual, and to what's in the spec.

Anyway, it's a slightly pedantic point, so I'm probably not contributing much to the conversation here :)

Re: Critiquing Facebook's new PHP spec

#20

Post by brian_mingus » Thu, Jul 31, 2014, 6:44 PM UTC

Critiquing the critique of Facebook's new PHP spec:

You used affect when you should have used effect. They probably don't teach that in the CS PhD program:)

Of course my post may be subject to Muphry's Law. But still. If you're going to spend so much time establishing your credibility, do you really want to ruin it by demonstrating you don't have a basic understanding of English grammar?

http://en.wikipedia.org/wiki/Muphry's_law