Phpstan deals well with type definitions, arrays are powerful enough to contain whatever needed, and functions can be stored and passed around easily enough.
Archaic maybe, but still brings a smile
!""
into the browser console just to be sure, during code reviews :D "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 string could be involved.!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 trueOne 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.
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.
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 them either in the constructor, immediately after creating an instance, or via some other method that guarantees they'll have a value by the time you need to read them (such as deserialization with validation).
If you want your properties to have a default "unset" value that you can trivially check for, that's what null is for. The author doesn't make it clear whether they are aware that you can declare a nullable string and give it the default value of null, but I hope they are.
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.
It's been debunked so many times over the years, I'm afraid I don't have the energy or desire to do it again when it's really not needed if you're far out of the php ecosystem that it really won't make a difference. Suffice to say the PHP it is talking about is nothing at all like modern PHP.
Surprisingly enough, I was more productive in PHP than I was in perl. Perhaps perl is even stranger than PHP.
I’ve been doing so Perl maintenance lately and I miss PHP. Perl is a lot weirder than PHP. If I didn’t know C or had dabbled in Perl before I would be completely confused. There is More Than One Way to do it (the Perl rallying cry) causes a lot of confusion. The one nice thing about Perl is that it doesn’t really change anymore, and you can see where it positively influenced others.