131–140 of 337 posts
Glad to see PHP still chugging along after all these years. It's the language I started with as a freelancer more than a decade ago and I still remember having books on my desk learning the proper way to do things, as you had to work around all the unsafe things the language would let you do and which unfortunately led to it getting a bad rep.
These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.
Earlier quoted context omitted.
> Especially if you have a mix of "old" procedural and modern OO php I guess thats a result of such wildly changing features in each version change. Each major version of PHP has brought in such drastic changes of concept and semantic that it is easy to start mixing them together and get confused looking code. However I find this in a lot of other systems. Look at node.js, every release changes things so much that pe…
I agree. I think for largely cultural and timing reasons, and also its success, there are a lot more long-lived php codebases for this to play out in compared to most languages. I also think possibly node is our generation's php, with it being so fast-changing and there not being a community consensus about framework. So every complex node project is, like pre-laravel php, essentially a totally unique ad-hoc framewor…
Earlier quoted context omitted.
I had similar thoughts, but do appreciate the additional mb_ functions bringing multi byte support to some remaining functions. Also people should be coding defensively with things like “if not defined” when implementing their own global helper functions (or avoid doing that at all)
"if not defined" doesn't help, if your own `array_find` doesn't have the same signature and semantics than the new global then you're screwed. You'd want the opposite: overwrite it if it already exists in the global scope (dunno if that's easy / how that'd work in PHP)
In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!
Earlier quoted context omitted.
Whats the problem with global namespace littered with utility functions. Do they get in the way? They hurt you? They whisper in your ear? Or with the badly named functions? Or the type juggling? Do they eat your soul?
It could be much easier for user defined functions to collide with standard functions, especially when it happens unintentionally. Someone else creates a function named array_something in the namespace. Maybe it already exists in earlier versions, maybe it happens to collide with one of the four introduced in 8.4. This function is accessible to you in the current scope. Now, you try to call the function like the way…
PHP functions can be namespaced. I can just write myLib\array_find, otherLib\array_find. You choose what implementation you want when importing. IDE will pick the correct one.
So, zero chances of collision.
Earlier quoted context omitted.
That's a wild perspective. Python has the worst packaging ecosystem i've ever seen
worse than javascript?
In python managing packages is a pain and there are too many package manager options, but for the most part there are good libraries, and chances are you don't even need one because the standard libraries are so good and mature.
In Javascript NPM is really all you need (even if yarn is a bit nicer), but you're gonna need to install 50 packages just to get a basic boiler plate app going and the quality of said packages is not always great.
Earlier quoted context omitted.
If we hitched language development on Wordpress we would still be on PHP4 as they refused to join gophp5 some seventeen years ago. Again, an ancient enough codebase which contains a library using array_find will need enough upgrades to run on PHP8 much less PHP8.4 the change from array_find to something else is the least of your worries.
Seriously? 2k results for array_find in PHP on GitHub: https://github.com/search?q=array_find++language%3APHP&type=... . RFC authors ( https://wiki.php.net/rfc/array_find ) explicitly noted over 600 hits for definitions of array_find, around 30% of which are not false positives - that is, there's a good possibility that there are 200+ implementations of global array_find in just open-source projects. First page hits…
https://github.com/hawind/gdoo/blob/master/app/Support/helpe...
Is namespaced. You need to realize that \array_find is different from \Illuminate\Support\Arr\array_find.
There is zero chance of collision here. Totally compatible.
I'm just a PHP programmer for work, but I worry about the orientation PHP has chosen. As French people say: better is the enemy of good (Le mieux est l'ennemi du bien). The two new language features bring a higher language complexity for dubious gains. I hope I won't have to work with these. Property hooks mean that some language magic will turn a property access into a call to methods. It implies that `$this->x` has…
Don't you get tired of managing getters/setters in your entities?
Glad to see PHP still chugging along after all these years. It's the language I started with as a freelancer more than a decade ago and I still remember having books on my desk learning the proper way to do things, as you had to work around all the unsafe things the language would let you do and which unfortunately led to it getting a bad rep.
One of the issues with creating a language that is easy to use (PHP, BASIC, and many modern languages), is that people who aren't good at programming, will use it. With predictable results. The difference between languages like PHP and more modern languages, is that the more modern languages have more airbags, for the bad code. It's still bad code, but it won't do as much damage. PHP is likely to be around for a long…