Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

These are things in PHP which make me sad

phpsadness.com

Post reply on HN
Print view View original

91–100 of 217 posts

Re: These are things in PHP which make me sad

#91

Post by PaulHoule »

rmason wrote: post #89
PaulHoule wrote: post #42

Earlier quoted context omitted.

that article is strikingly inarticulate. if you've got to tell me to scroll to the bottom, then it's a complete failure at selling railo, whatever it is

I am getting a 404 with the link right now. Railo is a JBOSS project that is an open source version of CFML. Here's what they say about Railo in comparison to PHP: • Simplicity More powerful tags for simple file, email, database and other common operations. • Best Practices Support If you want to build OO apps using TDD, you can do so. If not, you can still hack out working scripts in minutes. • Frameworks A wide ran…

you've got to be kidding; PHP is a better Cold Fusion than Cold Fusion ever was

Re: These are things in PHP which make me sad

#92

Post by wvenable »

As usual, when one of these lists comes out about PHP there are some real issues, some non-issues, some have been fixed, and a few things that are just different. I'm surprised these sorts of posts keep getting voted up here; haven't we seen it all before?

I do a lot of PHP development but not exclusively and rarely does these sorts of deficiencies in PHP ultimately matter.

Re: These are things in PHP which make me sad

#93

Post by ch0wn »

jrockway wrote: post #60
pornel wrote: post #16

There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!

public/protected/private is a dumb idea in dynamic languages. If you don't want someone calling your method, prefix it with an underscore and say "the results are undefined if you call methods that start with an underscore". Done. Easier to maintain, easier to test, less code to type in. Come to think of it... public/protected/private is a dumb idea in C++ and Java, too.

Agreed. When I started using python I thought that I would miss protected/public methods, but I was wrong. Conventions are the better solution and make testing incredibly easier.

Re: These are things in PHP which make me sad

#94

Post by jessedhillon »

jmathai wrote: post #34
gergles wrote: post #20

Earlier quoted context omitted.

Wow, a downvote within 30 seconds of posting? "php" == 0 returns true, and this makes sense how?

It doesn't make sense unless you understand how PHP works - at which point you'd use ===.

> It doesn't make sense unless you understand how PHP works ...

In other words: equality is not intuitive. Awesome!

---

Let's take a look at "how PHP works":

  0 == 08 // true!
WTF, really? Well, let's just use the magical 'I-mean-actual-equality-not-some-other-kind-of-equality' operator:

  0 === 08 // also true!

  (Sonofabitch/Facepalm) * Infinity
Of all the areas of a language in which one could gain expertise in, I think testing equality should not be one of the more difficult to master.

This is just stupid behavior. 08 is an invalid octal sequence, but no error is raised. You can't detect this condition unless you do your own pre-parsing before allowing PHP to try to parse it!

Re: These are things in PHP which make me sad

#95

Post by jessedhillon »

cag_ii wrote: post #32
gergles wrote: post #20

Earlier quoted context omitted.

Wow, a downvote within 30 seconds of posting? "php" == 0 returns true, and this makes sense how?

Because the string is first converted to an integer. "==" makes the comparison after converting types (see: Type Juggling in the docs) where "===" requires that the types be the same in order to be equal. Kind of weird the first time you see it, but it's a language design choice and does make sense once you understand it.

What doesn't make sense is the rationale for designing it this way.

Re: These are things in PHP which make me sad

#96

Post by pornel »

mrspandex wrote: post #21
pornel wrote: post #16

There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!

"#41 Cannot create a final abstract class" is borderline too

Indeed. In 5.3 you could have regular functions in a namespace, so there's no need to abuse class for that any more.

Other than that it smells like a variation of the singleton antipattern.

Re: These are things in PHP which make me sad

#97

Post by archivator »

koenigdavidmj wrote: post #8
thinkcomp wrote: post #6

I've definitely run into #1 on the list. "Paamayim Nekudotayim" is a transliterated version of פעמיים נקודתיים‎, which means "double colon" in Hebrew. Zeev and Andi are Israeli, which kind of explains it, but the error message is still pretty useless.

Even in Hebrew, that is a useless error message...token names should mean what the token means, not what it looks like.

Presumably, the tokenizer doesn't know anything about the meaning of the tokens it's extracting. It's the parser's job to attach meaning to tokens.

Re: These are things in PHP which make me sad

#98

Post by jwatzman »

cag_ii wrote: post #32
gergles wrote: post #20

Earlier quoted context omitted.

Wow, a downvote within 30 seconds of posting? "php" == 0 returns true, and this makes sense how?

Because the string is first converted to an integer. "==" makes the comparison after converting types (see: Type Juggling in the docs) where "===" requires that the types be the same in order to be equal. Kind of weird the first time you see it, but it's a language design choice and does make sense once you understand it.

But then it means that "==" is no longer transitive, which I see as very unnatural and confusing (even if the underlying reasoning sort-of makes sense).

Re: These are things in PHP which make me sad

#99

Post by code_duck »

VMG wrote: post #86
code_duck wrote: post #74

Earlier quoted context omitted.

You should check out JavaScript - the type coercion is similar but even worse.

but JS isn't behaving weirdly with return values. Overall, JavaScript is much less WTF than php.

It's impressive how they managed to do that, given that PHP is a single open source platform with one major implementation, in contrast to JS.

Re: These are things in PHP which make me sad

#100

Post by pornel »

jrockway wrote: post #60
pornel wrote: post #16

There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!

public/protected/private is a dumb idea in dynamic languages. If you don't want someone calling your method, prefix it with an underscore and say "the results are undefined if you call methods that start with an underscore". Done. Easier to maintain, easier to test, less code to type in. Come to think of it... public/protected/private is a dumb idea in C++ and Java, too.

I don't see how dynamic languages make it dumb.

Dynamic or not, objects have interfaces and this is a way of defining the public interface and catching violations of it.

> Easier to maintain, easier to test, less code to type in

My impression is opposite. They add friction to changing visibility. I like to start with everything private and then unprotect as needed.

It's extra character to type and it interferes with autocomplete.

Accessibility of "private" methods shouldn't be help in tests — you'll end up creating tests that depend on implementation. If class is too impenetrable to test, then refactor it (split concerns, add dependency injection, etc.), don't unprotect it.

Post reply on HN