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

201–210 of 217 posts

Re: These are things in PHP which make me sad

#201

Post by philjackson »

samdalton wrote: post #146
steve-howard wrote: post #134

Earlier quoted context omitted.

You can use the @ symbol to suppress errors when you're aware that the variable may be empty and you've considered the possible effects. When I used to write PHP, I'd often write something like do_something(@$_GET['foobar']); There are ways to suppress PHP notices without just turning off the E_NOTICE output.

It shouldn't be ok to write code that is known to throw an error, and handle it by suppressing that error. Silently failing code is just a bug waiting to happen. It's also making the interpreter do unnecessary error handling work when a simple "if ($_GET['foobar'])" would suffice.

It should be ok (the poor PHP implementation aside). Auto-vivification is something that's very useful in Perl and I miss it greatly in the languages I program in now. Being able to do this:

    $one->{ two }->{ three } = [ $four ]
Without having to check every link for definedness makes for cleaner code, IMO. Making it optional "suppressing that error" would be a good middle-ground.

Coffeescipt has the existential operator, not quite on a par with Perl's autovivification, which allows:

    zip = lottery.drawWinner?().address?.zipcode

Re: These are things in PHP which make me sad

#202

Post by code_duck »

steve-howard wrote: post #197
code_duck wrote: post #172

Earlier quoted context omitted.

It's inefficient to do that, as from what I understand PHP actually sets the error level to none, processes that line, sets it back, and continues. Also it would suppress any other warnings from that line, which could be unrelated to the supplied argument value. Instead, I use a 'get or else' function, as in some functional languages. For arrays, it goes function get_or_else($array,$key,$default=null) { return isset(…

I wasn't aware of that implementation detail. Hey, now I respect PHP even less than I did before. Your solution makes for some good boilerplate, but things like that are exactly why I use Python for everything it makes sense for: these things are baked into the language (in Python it would be array.get(key, default) ).

Yeah, it's part of Scala's type system, too - (Option, and Some or None. Better language designers go to great lengths to make simple things like null values well covered). Python will throw a fatal error and exits on reference to a nonexistent Dictionary key, but PHP blithely fills in the value with something falsy and continues.

I'd rather be using Python too, but for some apps we have to work with a lot of PHP legacy code, so I do what I can.

Re: These are things in PHP which make me sad

#203

Post by zokier »

EamonLeonard wrote: post #70

PHP is Open Source. Compiling a list like this is nice, but contributing something back, and getting involved in making improvements to PHP, would be nicer.

Many flaws in PHP are unfixable without breaking compatibility, and if you break compatibility you lose the only advantage that PHP has these days.

Re: These are things in PHP which make me sad

#204

Post by burgerbrain »

archivator wrote: post #97
koenigdavidmj wrote: post #8

Earlier quoted context omitted.

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.

Presumably, the programmers should pick reasonable token names for the sake of other programmers.

They're all just numbers to the tokenizer...

Re: These are things in PHP which make me sad

#206

Post by ceejayoz »

count wrote: post #174
ceejayoz wrote: post #139

Earlier quoted context omitted.

Again, bullshit. I've had PHP projects that were entirely command-line with no Apache and MySQL. If you want to argue that those projects weren't development, that's absurd. Systems and database administration are hugely complimentary skills, but someone who doesn't know anything about setting either one up is still developing.

I agree with you in a literal sense. I'd add the adjective 'extremely poorly' to 'developing' for any developer who doesn't have a thorough grasp of the system for which they are developing.

An artist can make great art without knowing the details of how the dyes in their paint are manufactured. The same is true for development.

Re: These are things in PHP which make me sad

#207

Post by samdalton »

philjackson wrote: post #201
samdalton wrote: post #146

Earlier quoted context omitted.

It shouldn't be ok to write code that is known to throw an error, and handle it by suppressing that error. Silently failing code is just a bug waiting to happen. It's also making the interpreter do unnecessary error handling work when a simple "if ($_GET['foobar'])" would suffice.

It should be ok (the poor PHP implementation aside). Auto-vivification is something that's very useful in Perl and I miss it greatly in the languages I program in now. Being able to do this: $one->{ two }->{ three } = [ $four ] Without having to check every link for definedness makes for cleaner code, IMO. Making it optional "suppressing that error" would be a good middle-ground. Coffeescipt has the existential opera…

The Coffeescript ? operator is certainly quite handy. I suppose it's explicit nature is what helps, as information on the error you're trying to mask is built into the syntax. With @ in PHP however, you simply don't know what it's trying to stop, and what undesirable affects it may cause, which I think is the main objection to it.

Re: These are things in PHP which make me sad

#208

Post by count »

ceejayoz wrote: post #206
count wrote: post #174

Earlier quoted context omitted.

I agree with you in a literal sense. I'd add the adjective 'extremely poorly' to 'developing' for any developer who doesn't have a thorough grasp of the system for which they are developing.

An artist can make great art without knowing the details of how the dyes in their paint are manufactured. The same is true for development.

Can an artist make great art without knowing to use oil paint on canvas, instead of watercolor (or whatever - I'm not an artist)?

How about knowing the difference between types of brushes and what effect they have on the canvas? Is it 'great art' if it's accidental?

Re: These are things in PHP which make me sad

#209

Post by rjh29 »

btilly wrote: post #152
rjh29 wrote: post #150

Earlier quoted context omitted.

Perl recognises that it is a bad practice. perl -we ' print "true\n" if "12" == "12php"' Argument "12php" isn't numeric in numeric eq (==) at -e line 1. true perl -w -e 'my $foo = "12php"; $foo = $foo + 1; print $foo, "\n";' Argument "12php" isn't numeric in addition (+) at -e line 1. 13 (an exception seems to be made for $foo++ though... that's Perl for you).

$foo++ isn't an exception. It has documented behavior on strings. That is sometimes very useful.

I meant it's an exception because it does not throw a warning, even though you are treating a string as a number. (This is contrary to $foo = $foo + 1). The DWIM string auto-increment doesn't even kick in unless the variable matches /^[a-z]/i.

Re: These are things in PHP which make me sad

#210

Post by rjh29 »

jessedhillon wrote: post #187
wvenable wrote: post #182

Earlier quoted context omitted.

> The fix for this is that foreach should create a new iterator variable which overwrites the existing one. That would be very strange behavior though that has no equivalence in any other part of the language. I'm sure if it did that, somebody would put on the list of things that PHP does weirdly! > That would preserve expected behavior. I'm afraid the behavior it has is the expected behavior. The problem isn't the l…

> That would be very strange behavior though that has no equivalence in any other part of the language. How is it strange? When you declare your iteration variable, it unsets any existing definition of that variable if there is one, before it inserts the new variable. Why would anyone enter a loop and expect the iteration variable to have a value defined outside the loop? Moreover, even if someone can find a reason w…

> Why would anyone enter a loop and expect the iteration variable to have a value defined outside the loop?

Thus us the takeaway point, I think. The loop would work perfectly fine if $bar was lexically scoped to the foreach, but it isn't. That's a general weakness in PHP compared to pretty much any other scripting language used today.

Post reply on HN