241–250 of 337 posts
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.
This would be a valid point 20 years ago. 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.
Read my comment and all previous comments again. Don't write such meaningless words and waste your and other people's time when you don't even understand what people are talking about.
A tool to avoid collision was introduced decades ago. This tool was made proeminent by the language and the ecosystem (PHP-FIG, frameworks, books, popular PHP celebrities).
You literally have to had stopped programming PHP more than a decade ago to not understand namespaced functions.
https://phptherightway.com/#namespaces
This problem of collision was seen miles ahead, and people were gently introduced to the idea that the global namespace belongs to PHP builtins and you should not pollute it even further.
I would say it is consensus for the PHP community that if your code broke because you defined array_filter globally before 8.4, then your code sucks and you don't know PHP.
If you want any evidence that terrible language design is alive and well in PHP, look no further than the new array_find function. Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $fi…
Earlier quoted context omitted.
Don't forget Laravel for PHP.
It’s difficult for me to trust a framework backed by venture capital ( https://blog.laravel.com/accel-invests-57m-into-laravel ). There are too many incentives to prioritize making money, which makes it easy to overlook developer experience. I rather use Symfony instead.
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…
PHP to me, professionally, is nothing without Laravel. So as long as Laravel doesn't become more obtuse than it already is, it's all good.
I really dislike getters and setters, particularly when they allow async code. Now all the sudden you have a massive performance risk, it's all too typical to see junior devs doing expensive stuff in getters and now the whole application, exponentially, becomes slower.
Anything that _may_ involves magic is dangerous in large code bases.
Earlier quoted context omitted.
Every step on the path to bloat is justified.
And yet in this wonderful laboratory of a multitude of languages the growth of a language doesn't destroy as much as it offers a larger variety of choice - with good features being stolen by other languages and less good features remaining niche and unique.
For how many years will it get support, security and bug fixes?
Earlier quoted context omitted.
That is a fine argument for setters, but I still don't see the connection between that, and the desire to disguise properties as setter methods.
Some light weight ORMs do not require you to define all the properties ahead of time. They pull the field names from the table and generate the model record on the fly for you. This generally lets you prototype really fast. Laravel's Eloquent is known to do this. It's also useful for derived SQL fields when you use custom queries or join from other tables. Also kinda fun to do it for properties backed by a method. As…
Earlier quoted context omitted.
There are many times I would love to have an automatic backing field in C#. C# will do that if you use the default setter but in cases where that's not possible I dislike having to both declare a separate field and having it available to the rest of the class outside of the setter.
C# 13 has this via the field keyword (as preview feature): https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... It's pretty similar to what PHP provides here, except that PHP uses "$this->propname =" and C# uses "field =". Edit: As someone involved in the RFC, it's somewhat funny, because we considered a special variable like "$field" or "$value" too magic, and C# does just that with a field keyword.
I used it in Unity projects to have serialized/inspectable values exposed through properties:
[field: SerializeField]
public int MyProperty { get; private set; }I was curious about why setting `$this->countryCode` inside the setter for `countryCode` didn't result in infinite recursion. Turns out this is spelled out in the RFC, but not in the docs: When a hook is called, inside that hook $this->[propertyName] will refer to the “unfiltered” value of the property, called the “backing value.” When accessed from anywhere else, $this->[propertyName] calls will go through the relev…