Live data from Hacker News

PHP's Oddities

flowtwo.io

41–50 of 186 posts

Re: PHP's Oddities

#41
Arrays in PHP are mostly confusing if you are used to them in other languages. Instead of $array[0] - the first element is accessed via array_first().

Having them as key-value means, that you can easily just remove some items in the middle, during iteration etc. No automatic shifting happening.

The thing which bites me is when some internal functions actually reindex the array. array_filter does not, but for example array_reverse, array_slice etc. do (preserve_keys always defaults to false). And for array_merge too, but there it's no array_merge(preserve_keys: false), but instead the + operator. (Why is this operator overloaded?!)

On the topic of the uninitialized state, as co-author of that RFC:

I agree with the author that nullable properties should have been auto-initialized to NULL. I haven't ever seen any benefit of an uninitialized state for these. Some co-authors of that RFC disagreed and wished for consistency with the other typed properties. The good thing probably is, that we still could opt to change this with a relatively minor BC break.

For non-nullable properties, I do think there is value. Not every value is actually available/ready in a constructor. Sure you can assign dummy values to properties. But it's requiring you to then manually guard/assert that the property is actually initialized. If you happen to access a non-nullable typed property without isset(), then your code is likely broken anyway and I'm grateful for the Error exception thrown.

Also, PHP has this peculiar feature of ReflectionClass::newInstanceWithoutConstructor(). This is forcibly having an object in an uninitialized state. Whether that feature should exist or not is a good question, but in practice it's helpful for object hydration for example. This was one further motivation to introduce the uninitialized state.

The author of the post suggests checking at the constructor boundary. But this doesn't inhibit objects leaking / not finishing the initialization properly. (class Foo { public stdClass $object; function __construct() { global $foo; $foo = $this; } } new Foo; $foo->object ... is now still existing? PHP doesn't have mechanisms to invalidate objects at a distance. That would be the alternative, but also spooky.) Some choices need to be made, and all choices will have some rough edges.

Side note: I personally never use is_null(), but nearly always isset(). This nicely checks for the uninitialized state too. Static analysis tells me anyway, when I access a variable or property name which can never exist.

Re: PHP's Oddities

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

> Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem I heard this a long time ago about perl. CPAN is great. Well ... perl entered the fossilized era. I think people do not really observe things correctly. I am noticing the same with ruby right now - everyone sees that ruby is in decline, very strongly so, in the last 3 years. Yet you have blog posts suc…

People absolutely have VERY strong opinions and voice them constantly. True of every language but especially php. Almost feel like it’s more acceptable to rant about php than to praise it

Re: PHP's Oddities

#44
post #40

Earlier quoted context omitted.

I’m well aware of them. I’m not sure I agree with “better”.

I’m very curious to hear your take on this. I started out on PHP for about 4-5 years then moved on to Ruby and JS. I never once had any fond thoughts for PHP’s split-personality array thing. So I’m very curious what it is that other people appreciate about it.

Having to switch implementations and potentially functionality because, say, the order of the collection matters now is rather annoying, IMO.

Re: PHP's Oddities

#45
I like the arrays, they make it feel like a bit of a low level language and there are some weird tricks one can do with them. As for class property behaviour, I kind of get nervous if my properties or the constructor don't enforce default values I can then fit into downstream logic.

One of the best things with PHP is PsySH, or "Tinker" as the laravelists call it. It's not a REPL in the Common Lisp sense, but it is quite nice for an interactive programming shell. I've spent countless hours solving problems very, very quickly in it, and alongside Picolisp pil + and Elixir iex it's one of the earliest tools I install on a new system.

https://psysh.org/

The thing I miss the most is a nice concurrency story. It has become better but it's still a bit of a mess, often it's nicest to just implement workers as PHP and then implement control somewhere else, e.g. Elixir, or grab one of the application servers that are nowadays a thing in PHP.

Re: PHP's Oddities

#46

Earlier quoted context omitted.

> Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem I heard this a long time ago about perl. CPAN is great. Well ... perl entered the fossilized era. I think people do not really observe things correctly. I am noticing the same with ruby right now - everyone sees that ruby is in decline, very strongly so, in the last 3 years. Yet you have blog posts suc…

People absolutely have VERY strong opinions and voice them constantly. True of every language but especially php. Almost feel like it’s more acceptable to rant about php than to praise it

I attended a talk by Rasmus Lerdorf at a FOSS conference in 2006. It has been a long time, so I remember only a few things from the talk, but one thing I remember him talking about is how people love to complain about PHP, often on forums that are themselves written in PHP.

Re: PHP's Oddities

#47
post #29

I think the “bad rep” is coming from developers that stopped developing themselves.

A lot of it came from the rather harmful "php a fractal of bad design" article that used to get posted everywhere despite being highly inaccurate and out of date. Thankfully its fairly rare to see someone daft enough to still try using it in a discussion. PHP's come a very long way since then.

What is inaccurate about it? Maybe it is out of date now, but when I first read it about a decade ago, when I did a fair amount of PHP development, I had personally encountered most of the issues mentioned in there.

I've heard that PHP has improved a lot since then, but I don't see how you could really fix all the inconsistencies, global state, and "oddities" without a lot of breaking changes and really making it into a different language.

Re: PHP's Oddities

#50
post #39

Earlier quoted context omitted.

I knew this in and out, but as a Full-Stack PHP/Symfony/Frontend/JS guy who pivoted to mainly TS for b2b stuff, I still have to occasionally enter !"" into the browser console just to be sure, during code reviews :D

In JS/TS: "0" == false : true "" == false : true " " == false : true "1" == false : false !"0" : false !"" : true !" " : false !"1" : false In PHP: "0" == false : true "" == false : true " " == false : true "1" == false : false !"0" : true !"" : true !" " : false !"1" : false Honestly the only way to remain sane in either, but especially if you use both, is to always use === and never use boolean logic (!) when a str…

That's what I say in code reviews as well. Same for numbers.

!someValue is useful only for:

- booleans, including optional booleans (which is why every bool flag should default to false)

- undefined, null (falsy), or object/function (truthy)

It's nice for the second variant to also cover falsy NaN or things like this, for example for forms.

I guess that's where

  !!""===false
comes from.

But it's this exact case that keeps tripping me up.

What about empty arrays?

Per my original comment, now I'd have to look up if

  ![]
is false in PHP, or just empty([]) === true

.

So yea I agree, and extend your case to PHP "arrays" (in JS,

  !![] === true
is

  true
Post reply on HN