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

PHP's Oddities

flowtwo.io

Post reply on HN
Print view View original

171–180 of 186 posts

Re: PHP's Oddities

#171

Post by artyom »

moebrowne wrote: post #147
artyom wrote: post #132

Earlier quoted context omitted.

I agree, as I was one of them. Rightfully so, because PHP 20 years ago was the prime example of a complete disaster. Not just occasionally, there were long years of incompatibility, missing implementations, incoherent errors, security issues, fragmentation, etc. Paid my share of dealing with those problems with PHP 5 and 6 (after coming from PHP 4). I think it became a more sane ecosystem around very late 7.x to 8. I…

> Paid my share of dealing with those problems with PHP 5 and 6 Hard to take this seriously when there was no PHP 6. https://ma.ttias.be/php6-missing-version-number/

Correct.

If you were there, you'd remember the UTF8/Unicode fiasco (how long it took, how many people was both relying and struggling with it, and how they needed to cover it up after even some hosting providers attempted a beta upgrade and had to roll it back).

There was a PHP 6 (I'm including the non-updates in PHP 5 "waiting" for it), they just had to rewrite history as of PR damage control back then. That's what the article you linked describes, pretty much.

Re: PHP's Oddities

#172

Post by bakugo »

xp84 wrote: post #92
bakugo wrote: post #14

> This example exposes the "uninitialized" state that a property can be in, which is NOT the same as NULL. This distinction frustratingly comes up when you try to do a null check on these properties: If you're accessing an uninitialized property or checking if a property is uninitialized, you're probably already doing something wrong. The point of class properties with no default value is that you're supposed to set…

I think anyone would agree with the “you’re doing something wrong” part, but if you declare that a property is typed and non-nullable, it would be nice if a constructor that didn’t populate its non-nullable properties would cause an exception to be thrown or something, as the constructor didn’t construct a valid object by its own specification. The wrongdoing was in the constructor so the constructor should be where…

In theory, that can happen, yes, but in practice, it hasn't been a problem for me.

Good third party libraries generally don't leave uninitialized properties laying around for you to trip on, and I find the ability to set non-nullable properties after the constructor to be quite convenient for things like Symfony entities.

Re: PHP's Oddities

#173

Post by thayne »

kro wrote: post #89
mdavid626 wrote: post #25

Earlier quoted context omitted.

If I have an “array” and can do array[0] to get first item, but when I filter this array and array[0] throws an error, that’s super weird. What is the meaning of [] or what is an array even? The language forces me to understand how it is implemented under the hood. That’s exactly what the author says: leaky abstraction.

That also often shoots you as when json_encoding it only becomes an array when ordered "correctly" (numeric 0-based keys without gaps), otherwise an object. So to be safe you generally need to array_values after filtering. If in your testdata you only remove elements from the end you don't catch that before production data hits. To get the first element there also is reset(). I love PHP though.

It's especially problematic when encoding an empty object to json. By default an empty array is serialized as [], to get {} you either need to pass a flag to force object serialization (which can mess up serializing actual arrays), or cast the array as an object. Neither of which are great when the object is deeply nested in the serialized object.

Re: PHP's Oddities

#174

Post by thayne »

yurishimo wrote: post #95
blanched wrote: post #81

Earlier quoted context omitted.

I'm not familiar with PHP, can you elaborate on what you mean here? What is it compiling? Or are you referring to type safety?

When a php file is loaded at runtime, it runs through a very basic JIT compiler that does statically check a few things before continuing with execution. Syntax, for example, is checked for the entire file during this step. Most type checking happens at runtime (this might not be true for interfaces at some level, but I can’t say for 100% certain - I just know I tend to see interface related errors earlier during cod…

Is there a way to run type checking ahead of time similat to typescript or python's mypy or pyright?

Re: PHP's Oddities

#176

Post by hexciple »

mfonda wrote: post #9

After over two decades of working in PHP, I'm now working in Java. PHP is basically Java-lite. I am absolutely loving the compile-time safety of Java, but I dearly miss PHP's maps and arrays. In Java, the amount of verbosity for defining a map/list and operating on it is overwhelming. Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem, and decent enough…

Just had a bug the other day where we were array_filter and then feeding the results into json_encode. If you feed a sparse array into that, you get an object, not an array, which can then cause JavaScript Problems.

I wasn't aware of either of those behaviors going into that debugging session.

Re: PHP's Oddities

#177

Post by chuckadams »

moebrowne wrote: post #149
userbinator wrote: post #144

Earlier quoted context omitted.

That's exactly what I was expecting to read about upon seeing the article title. But apparently they deprecated and then changed(?!) the associativity in the past few years, which if anything just makes things even more confusing.

This changed 6 years ago in 8.0, a major version change. Once again showing how out of date peoples hate for PHP is

Ternary was made non-associative in 8.0, so it requires parentheses. It will become right-associative in 9.0. But there’s not much use case left for nested ternaries in PHP since the `match` operator was added in 8.0.

Re: PHP's Oddities

#178

Post by asddubs »

bwoebi wrote: post #78
idoubtit wrote: post #63

Earlier quoted context omitted.

There's one problem with arrays that I haven't seen mentioned here or by the OP: when inserting a key-value, the type of the key may change. For instance ["4" => "four"] === [4 => "Four"] This can lead to some unexpected behaviors. For example, I've already been bitten by `array_merge()` whose result is different if its parameters are arrays with numeric indexes. array_merge(["4 " => "four"], ["5 " => "five"]) // ["4…

The key type changing is generally not a problem per se, but it's definitely odd with the default re-indexing behaviour depending on whether something is integer keys only or not. That's exactly what I've been complaining in my post above. If there were no automatic reindexing, then this wouldn't be a problem either.

It's surprisingly rare that it becomes a problem, but I've definitely been bit by it before when getting array keys, expecting them to be strings and doing === comparisons.

Re: PHP's Oddities

#179

Post by nsonha »

mfonda wrote: post #9

After over two decades of working in PHP, I'm now working in Java. PHP is basically Java-lite. I am absolutely loving the compile-time safety of Java, but I dearly miss PHP's maps and arrays. In Java, the amount of verbosity for defining a map/list and operating on it is overwhelming. Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem, and decent enough…

Isn't kotlin a more modern choice coming from java, that's designed propperly instead a series of bolted on decisions?

Re: PHP's Oddities

#180

Post by Yokohiii »

chuckadams wrote: post #163
Yokohiii wrote: post #114

Earlier quoted context omitted.

Not sure why a language that barely has a type system needs generics.

PHP has had a type system for over a decade now, including things like union and intersection types that are still not in Java. Most static checking still needs an external analyzer, but even without one, PHP does check subclasses and interface implementations for Liskov substitutability in a way that Python does not.

I know all that. The issue is that the type system only cares about classes and interfaces. It's all userland abstract types. If a type system doesn't offer safety AND efficiency (i.e. for primitives) I see no value for me. I don't see that happening.
Post reply on HN