[dead]
PHP's Oddities
101–110 of 186 posts
Re: PHP's Oddities
#102Re: PHP's Oddities
#103I think the “bad rep” is coming from developers that stopped developing themselves.
I think the biggest problem is that the main way to use it is as a HTTP response handler, whereas other languages are more general purpose.
So when a developer wants to develop themselves outside of a HTTP response handler, they need to switch languages.
Of couse it can be argued that PHP can be used outside this one way as well, but even e.g. https://symfony.com/doc/current/mercure.html is using golang.
Re: PHP's Oddities
#104Earlier quoted context omitted.
I've written PHP off and on since the .php3 extension was a thing, and I can say that PHP very much deserved the bad rap it had for some time. It's evolved beyond most of that, but a lot of that is due to the composer ecosystem making up for it while the behavior of many builtins remains beyond repair. Which is fine, every language has baggage and warts. PHP's warts are sometimes heinously ugly, and they're on full d…
The most under appreciated thing about PHP is the fact that after 20+ years I can still develop in PHP and never had to learn a JS framework, Rust, Go, Ruby, Java or .NET.
?? you can write JS without having to learn a framework. They exist in PHP too such as Symfony. This constant complaint about frameworks seems less about the framework and more about having to learn to work with people which is partly why the framework abstraction exists.
Re: PHP's Oddities
#105I hadn't done any PHP in almost 20 years, not since my studies when LAMP was still the way to go. But recently I had a reason to create a dynamic web page (not what I usually do) and went with PHP. Haven't regretted it.
I haven't run into any of the quirks. I keep things simple, and it just works. The only problem I ran into was the realization that PHP is the wrong tool for long running tasks. After some rogue requests/users running my whole service to ground, I had to move the long running endpoints to node.
Re: PHP's Oddities
#106Earlier quoted context omitted.
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 k…
Obviously it depends what you're working on, what your patterns are, and so on. But my experience is that PHP involves so much array wrangling that devs are more likely to have a handle on what an array will do in this context (an empty array is falsy).
It's the string ones (in particular that in addition to the empty string, "0" specifically is the only other falsy string) that tend to catch people out.
Re: PHP's Oddities
#107Earlier quoted context omitted.
Better than calling it a hash.
I don't think it is, tbh. Perl's hashes are a complete mystery to me still, but at least it lets me know that it's not just a linear, uh, well, array.
> Perl's hashes are a complete mystery to me still
They're unordered mappings from strings to arbitrary values ("scalars" in Perl jargon). In this sense they're just like an object in JavaScript.
Where this gets a little weird is that Perl arrays and hashes are fundamental types distinct from scalars - you can't put a hash into a $variable without taking a reference to it first, for instance. But that's more a matter of Perl being picker about the value/reference distinction than a hash-specific thing.
Re: PHP's Oddities
#108Earlier quoted context omitted.
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 int…
The essay was largely accurate when it was written in 2012. We are living in the grim dark far future of the year 2026, and PHP has now addressed many of the issues it raised.
Re: PHP's Oddities
#109After 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…
Maps should be a first class type in every language.
I have this thing I want to do in C. Now my C is very weak so my plan was to do a prototype in python, keeping in mind the C ecosystem then sit down with my old copy of "The C Programming Language" and struggle through it. Doing it with no dicts was rough.
I am normally the sort to avoid adding any libraries I don't have to but if anyone has any hints to simple hash maps in C I am all ears.
Re: PHP's Oddities
#110Earlier 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…
One form of type checking does happen at compile time (which is really load time in PHP, but close enough), namely when a class extends another class or implements an interface: the types of every method and property are checked to ensure that they are substitutable per the standard variance rules (return types are covariant, parameters are contravariant, props are invariant). Everything else is checked at runtime though, and statically analyzing any of those is left to external tools like phpstan, psalm, or mago.