16 ms·

PHP 8.4

486 points by theThree 2y ago

inglor_cz 2y ago
I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or is it better to wait for a few months and let someone else catch the early errors?
- Dachande663 2y ago
  The last few point releases have been very stable, so normally within a week or so. Obviously this relies on having a pretty good test suite (we run ~8,000 tests in ~60 seconds so not too bad for us).
- TimWolla 2y ago
  For PHP 8.3, we upgraded production during the RC phase, but were prepared to revert back to an older one by not relying on the new functionality. Docker makes this easy. As long as you do not use the new functionality, I'd claim that a new PHP version is no less stable than an older one. And on a contrary you would be missing out on some bugfixes that were deemed too risky to apply to an existing version. Disclosure: I've got a commit-bit for PHP, so we had in-house expertise to diagnose issues ourselves.
- deleted 2y ago
  [deleted]
- edhelas 2y ago
  Basically I follow Debian Stable releases and migrate all my code to it when a new version is pushed. So so far I'm on 8.2. It also often fit with the current Laravel version (11).
- DaiPlusPlus 2y ago
  > how long do you wait before migrating to higher version of PHP? I still have a PHP5 project that somehow still runs.
- bawolff 2y ago
  Wikipedia is still on php 7.4.33 so don't feel too bad if you are behind.
  - inglor_cz 2y ago
    8.2 and 8.3, respectively. I enjoy the PHP 8 new features such as named arguments, constructor arguments promotion and nullsafe operators. Made my new code a lot more readable. I am not that sure about 8.4 yet, though the new array_ functions and new DOM look interesting.
  - Cthulhu_ 2y ago
    For a project like Wikipedia, stability and continuity are far more important than latest and greatest feature support; in fact, there's an argument to be made to avoid newer language features to ensure consistency, that is, if new features are used, they should be used everywhere at once. Else you end up with frankenstein code where every file could use a different style.
    - inglor_cz 2y ago
      "Else you end up with frankenstein code where every file could use a different style." Yeah, this is a huge problem, but also, in the long run, inevitable. Plenty of Kernighan & Ritchie C code still out there...
      - wbl 2y ago
        Almost none: ANSI was over 30 years ago and enough of an improvement people switched. If you mean C89 then yes, loads of it.
        skissane 2y ago
        It helps there are automated tools for converting old style K&R function declarations to the new ANSI/ISO style, like protoize. But K&R C is now so dated, protoize was removed from GCC 4.5 and onwards. When (in a bout of idiosyncrasy) I wanted to convert some ancient K&R C to new style a couple of years back, I ended up putting GCC 4.4 in a Docker container to make it easier: https://github.com/skissane/protoize https://github.com/skissane/protoize
- jspaetzel 2y ago
  I usually wait 6mo to a year in order for composer dependencies I use to get updated. Then its usually a trivial upgrade. I've upgraded sooner before for simpler projects though and things are usually pretty stable upon release.
- dubcanada 2y ago
  I wait one version, I’ll upgrade to 8.3 now and 8.4 when 8.5 is out.
- pilif 2y ago
  We start making sure our application runs on the next version around the time Beta 1 comes out. We upgrade the development environment around the time when our tooling (phpstan, cs-fixer) runs on the next version, but doesn't necessarily support new language features. We upgrade the production environment when our tooling supports most of the new language features and at least all of the ones we want to make use of. This usually happens within 3-6 months of the release. By that time the version has stabilized enough to be safe for production use.
- kugelblitz 2y ago
  Solo Dev on my own PHP project since 14 years. I wait 1-3 months, but then update. It used to take way longer, because Amazon's Elastic Beanstalk platform would take longer to update, but I've now changed to Platform.sh and the transition should be easier. It has been very backward-compatible (i.e. stuff that works in 8.n also works in 8.n+1; and unless you use exotic functions or are relying on special functionality, it should work for you, too). Once I'm at 8.4, I would slowly update the code / syntax with rector and the assistance of phpstan. For framework updates I wait 1-2 patch versions before updating, because of composer dependency problems and sometimes bugs do still find themselves into new releases (e.g. I would wait at least until Symfony 7.2.1 before upgrading from Symfony 7.1.x).
- stronglikedan 2y ago
  I wait until I need a new feature, or if there's a security issue. I still have PHP 5 apps in production.
  - crowcroft 2y ago
    Didn't PHP 5 stop getting security updates more six or seven years ago? I guess depending on the app that might not really matter, but that seems like it could be an issue at some point.
    - giraffe_lady 2y ago
      There's an entire ecosystem of companies doing support and proprietary security patches and even framework-bearing polyfills for php 5. So much of the web runs on php 5 that is never ever going to be updated. It's a mini-industry unto itself. The licensing is on the order of thousands or low tens of thousands per year. Worth it for a 40-person business that has a 20-year-old legacy codebase supporting a few million dollars a year revenue. It's not what we think of as a standard "tech" company but it describes an absolutely ridiculous number of businesses.
- artificialLimbs 2y ago
  We’re still on 7.4 at my mid co. =|
- eamann 2y ago
  I'm just waiting for the official PHP Docker images to bump their updates ... which should be any time now.
- ransom1538 2y ago
  We leave it on staging for about 4 months, scan logs etc. If there is no complaints from qa or devs we roll it out.
- gog 2y ago
  Usually the release is fine, but dependencies can be lacking in proper support/testing of the newer versions, so it takes a couple of months. Also external tooling, like for example NewRelic extension, takes some time to release a version that supports the new release.
mg 2y ago
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.
- aedis 2y ago
  Don't forget Laravel for PHP.
  - orangepanda 2y ago
    I had hoped to forget
    - BafS 2y ago
      You don't like magic? /s
  - mg 2y ago
    To get to know Laravel, I forced myself to build a project with it for a few weeks and I did not like it. I found myself getting sucked in into a complex project structure and dealing with all kinds of strangeness like "artisan commands", "the autoload cache" etc. With Django, I can build a web application in a single file that has "import django" on top and take it from there: https://news.ycombinator.com/item?id=40788329 https://news.ycombinator.com/item?id=40788329
    - conradfr 2y ago
      You can do that with Symfony. https://symfony.com/doc/current/configuration/micro_kernel_trait.html https://symfony.com/doc/current/configuration/micro_kernel_t... https://symfony.com/blog/new-in-symfony-7-2-simpler-single-file-symfony-applications https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...
    - 2y ago
honzaik 2y ago
[flagged]
- kyleee 2y ago
  That was my first thought as well, I have never been annoyed with the explicit parens when instantiating and using a class inline
reconvene1290 2y ago
> PHP 8.4 is a major update of the PHP language. No it’s not: it’s a MINOR update.
- dadver 2y ago
  It can be a major update even though it's a minor version bump.
  - pwdisswordfishz 2y ago
    It could have been, but isn’t. Most of those are rather small, incremental quality-of-life improvements. Nothing revolutionary.
    - theodorejb 2y ago
      I wouldn't consider all the new features small, but even many small improvements can result in a major improvement.
anttihaapala 2y ago
Oftentimes many of the significant new PHP features are to fix the shortsighted implementation in the previous ones - for example this method chaining with `new` - there was precedent already, C++ got it right well before PHP even existed and with the very same arrow operator that PHP borrowed (and so did Java and JavaScript with .), so the question is why did PHP have to get it wrong at first and for so long. Another pet peeve of me is that the global namespace is littered with these utility functions that should be easily composable or maybe be methods on the objects themselves - and looks like PHP 8.4 adds four more `array_*` functions. For comparison, Python's builtin namespace has a total of 71 functions and a couple of exception classes. PHP's builtin namespace has more functions for dealing with arrays and now 58 of those are prefixed with `array_`.
- dubcanada 2y ago
  The global namespace change would break everything. It’s unlikely they would ever do something like that. It’s hard to build on a language used by so many, when you can’t modify the base. Python decided to do 2.7 vs 3 and fragmented the eco system terribly.
  - nneonneo 2y ago
    They could help by not adding any more cruft to the global namespace. Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the built-in function. Sure, you can’t touch the existing pile of globals, but at least stop pouring fuel on that particular fire…
    - chx 2y ago
      That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways. Surrendering the global namespace to the language is not so bad an idea.
deleted 2y ago
[deleted]
idoubtit 2y ago
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 a different meaning if it's inside a hook or outside hooks. I've used this kind of feature (getters/setters) with JS code (and with Moose/Perl decades ago), and I wasn't convinced. Plain methods are more explicit, have less cognitive charge, and are easier to extend. On the bright side, I'm glad that the language is still thriving. In 2021, I was worried when the foundation was created, especially as I read that Nikita Popov had left. He was the creator of PHP's JIT code, and at the time the only developer who could fully understand it. But it seems there was no need to worry. PHP is now longer "the elephant in the room" of web programming, but it's still a good language, with many active developers at its core.
- dubcanada 2y ago
  None of this is required. You can still write spaghetti code perfectly fine.
  - smarkov 2y ago
    Of course it's not required but when you start pushing the boundaries of a language with the goal of achieving a clean interface, obscure features you wouldn't normally resort to become appealing. I dislike all of the magic around Laravel's Eloquent ORM - model relationships, query builder, abuse of ForwardsCalls trait, etc, but at the same time I can appreciate how "clean" it all looks once it's put together.
- beberlei 2y ago
  Just to set the record straight, Nikita is not the creator of the PHP JIT code, that is Dmitry and he is employed by Zend owned by Perforce working mostly on this.
  - idoubtit 2y ago
ycuser2 2y ago
[flagged]
- wayvey 2y ago
  Wrong thread?
deleted 2y ago
[deleted]
nneonneo 2y ago
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, $filter_callback) while the older array_search is ($search_value, $array). There are literally hundreds of hits for existing, global, functions named array_find. If these are loaded from a library, they will break uses of the new built-in function in exciting ways. Yet, even with this mentioned in the RFC (https://wiki.php.net/rfc/array_find https://wiki.php.net/rfc/array_find) it seems to have been no obstacle whatsoever to its inclusion - despite the fact that the implementation is literally three lines of code. I have to question if the benefits of this global function really outweigh the benefits. PHP devs claim that other languages have these functions so PHP should too - but neglect to note that most languages don’t make them global functions (rather, they’re usually array methods or in some utility module).
- kyleee 2y ago
  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)
  - williamdclt 2y ago
    "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)
    - asddubs 2y ago
      the answer is using a namespace
    - 2y ago
theodorejb 2y ago
Property hooks are the headline feature, but they seem like something I'd rarely use in practice. It is nice to have the option available though, in case I need to add extra logic to a property without breaking everywhere that it's accessed.
- IluTov 2y ago
  > A primary use case for hooks is actually to not use them, but retain the ability to do so in the future, should it become necessary. My personal motivation was always to finally put an end to the getters/setters boilerplate.
tored 2y ago
Great PHP release. Better stack traces for closures, performance improvements (always nice), HTML5 support, lazy objects and much more. Great work and a big thanks to everyone involved!
- LkpPo 2y ago
  IMHO the HTML5 parser is the best improvement of this version.
cbg0 2y ago
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.
- ChrisMarshallNY 2y ago
  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 time: https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...
  - inerte 2y ago
    > With predictable results. People building and creating awesome new things? Increase in happiness and empowerment? More efficient processes and increase in productivity? New businesses being born? Wealth and value being added to society?
    - ChrisMarshallNY 2y ago
      > More efficient processes and increase in productivity I'd have to see the numbers on those ones. But I am not a "gatekeeper" type, maybe you are confusing me for one. I'm a high school dropout with a GED, and have been staring up people's noses, all my life. I just believe that any job we do, should be a good job. Build on a sand foundation, and you'd better not go too high, or Bad Things Happen.
      - deleted 2y ago
        [deleted]
vfclists 2y ago
For how many years will it get support, security and bug fixes?
- philipwhiuk 2y ago
  Support: 31 Dec 2026 Security: 31 Dec 2028 Bug Fixes: 31 Dec 2026 From https://www.php.net/supported-versions.php https://www.php.net/supported-versions.php
- nedt 2y ago
  If needed you can get LTS from Zend. They still offer security fixes for 7.2 until end of 2026 and 8.3 is supported until end of 2029. But that's just if upgrading every second or third year is too expensive to you.
  - chx 2y ago
    Zend offerings are confusing. https://www.zend.com/services/php-long-term-support https://www.zend.com/services/php-long-term-support only lists 8.0 and earlier, https://www.zend.com/products/zendphp-enterprise https://www.zend.com/products/zendphp-enterprise does have a chart showing 8.3 into 2029 but once again the text only mentions 8.0. What gives?
    - nedt 2y ago
      Anything after 8.0 is not EOL. Security support for 8.1 is still provided by PHP itself until end 2025.
KRAKRISMOTT 2y ago
Are there any solid PHP WebSockets and WebRTC setups outside of Laravel?
- kyleee 2y ago
  Symfony? Or is this a case where Laravel has actually built out their own packages for support in these two instances?
- hipadev23 2y ago
  swoole makes websockets extremely easy and fast. webRTC is a beast with the STUN server needs better handled elsewhere.
- josephscott 2y ago
  Workerman has WebSocket support - https://manual.workerman.net/doc/en/appendices/about-websocket.html https://manual.workerman.net/doc/en/appendices/about-websock...
chx 2y ago
oooo variable-length lookbehind assertions are now supported. yay! I needed that so many times.
- bwoebi 2y ago
  While variable-length lookbehind is surely more comfortable to work with, I found clever usage of \K to be largely sufficient in most cases. But I agree, a great feature!
cute_boi 2y ago
I can see PHP is getting too much complex.
- wvenable 2y ago
  You trade complexity in source code for complexity in language. For example, property hooks will make code that currently uses other methods to accomplish that task much easier to read and write.
trevor-e 2y ago
The property access is looking a lot like Swift, particularly the `private(set)` part which I haven't seen in many other languages.
littlestymaar 2y ago
I find it pretty fascinating that what used to be a beginner-friendly language, with limited capabilities but that is very easy to get started with, has now evolve to a bloated monster full of advanced features that you can't expect to know entirely, with a complex framework and tooling ecosystem to support it. PHP lovers generally don't like acknowledge that, but the PHP we've learned back-end development two decades ago is no more and that it's now as beginner unfriendly as Java was when we picked it. It's a pity because there's nothing as beginner-friendly anymore. I think the blame is on people calling themselves “PHP developers” who never bothered learning more advanced languages after PHP and instead pushed PHP to reach parity with those, at the expanse of losing its soul.
- deleted 2y ago
  [deleted]
- ceejayoz 2y ago
  You can still write the old PHP4 way in virtually all cases. <?php echo('hello world'); ?> works fine. I've done so periodically, and every time I go "this sucks, gimme the tooling".
  - littlestymaar 2y ago
    Sure, and I'm still using PHP every once in a while for personal needs (I have a handful of small personal websites built this way: PHP has this insanely cool capability of being just a scripting language for a basic dynamic website). What's sad is that it's not how people use and teach PHP today. PHP's magic really is that you can write small scripts super easily to do small tasks, but somehow most PHP developers insist that “no PHP isn't for building small scripts” but “a real, professional back end language ready for mission critical enterprise requirements blah blah blah”, because surely that make them sound more serious as programmers, missing the point entirely… (And sorry to all insecure PHP programmers out there, but for serious stuff using PHP is still equivalent to coding with handcuffs and you should really learn a second programming language at last because being a one trick poney really isn't as cool as you think it is).
- 2y ago
acabal 2y ago
I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. 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!
- Xeoncross 2y ago
  I'm curious, why do you like getters and setters? I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life. It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that perhaps we shouldn't be doing this.
  - munk-a 2y ago
    I've always been a fan because if a property turns from a simple value to a more complex interaction that might involve DB operations or other side effects then if a getter is in place you can modify the logic without needing to update widespread code.
    - hamandcheese 2y ago
      If you are replacing a performant property with a slow network call, you are being negligent if you aren't reviewing all the callers to make sure that is okay.
      - hparadiz 2y ago
        In a typical ORM when you do say $Model->DateTime = 1732046457; the __set is actually checking the value and seeing oh it's an integer. Treat this as a unix timestamp. But when you run save() the query is actually converting that to a Y-m-d H:i:s (for MySQL/MariaDB). This doesn't actually happen until you run save() when it makes the query and runs the network call. Most of that time it's actually storing everything in memory. But you might want to support string date times and the PHP object DateTime as well. So a typical well designed ORM converts multiple PHP types into a SQL string for saving. That's what the historical __set and __get are all about. This is called "mapping" by most ORMs and a very well designed modern one like Doctrine will actually have mappings for different SQL storage engines available. Obviously it also has to handle the reverse.
PaulHoule 2y ago
That “public private(set)” boggles my mind. Why not “readonly public”?
- wvenable 2y ago
  Readonly might have different semantics (as it does in C#). Readonly has been discussed but it wasn't part of the property hooks RFC and is a separate issue/feature. This is just a natural consequence of having private setters.
- bwoebi 2y ago
  readonly is rather a misnomer for "writeonce" in PHP. And as such it also disallows repeated assignment in class scope, while private(set) has no such restriction.
radicalriddler 2y ago
The new Dom stuff looks really cool. I had to work with the previous functions a couple months ago and it was terrible. New API looks nice.
TheRealPomax 2y ago
Standards compliance for HTML is huge. Hopefully everyone switches to it ASAP.
- dmsnell 2y ago
  DOM\HTMLDocument is a huge boon. Niels Dosche incorporated lexbor into PHP to do so, and it maintains the same interface as DOMDocument once it’s instantiated. In case people aren’t aware, DOMDocument is dangerous. You can’t parse HTML with an XML parser; so everyone currently using DOMDocument for HTML would benefit by replacing that with DOM\HTMLDocument immediately, eliminating both security and corruption issues. Have you tried using an HTML parser?
dzonga 2y ago
[dead]
bornfreddy 2y ago
Am I the only one excited about bcmath objects? Not so much because of arithmetic operators, but mostly because now we can do data types checks without resorting to wrapper classes. Nice!
eurleif 2y ago
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 relevant hook. This is true for all hooks on the same property. This includes, for example, writing to a property from the get hook; that will write to the backing value, bypassing the set hook. A normal property has a stored “backing value” that is part of the object, and part of the memory layout of the class. However, if a property has at least one hook, and none of them make use of $this->[propertyName], then no backing value will be created and there will be no data stored in the object automatically (just as if there were no property, just methods). Such properties are known as “virtual properties,” as they have no materialized stored value. Be aware, the detection logic works on $this->[propertyName] directly at compile time, not on dynamic forms of it like $prop = 'beep'; $this->$prop. That will not trigger a backing value. Feels like too much magic to me that a property access can mean different things depending on context, but I'm not a PHP user, so I don't get a vote.
- tail_exchange 2y ago
  I'm also not a php developer, but I agree. This seems like a huge footgun. I've never been a fan of this kind of magic, and I wonder how other languages deal with this case.
  - crimsonnoodle58 2y ago
    Well in python I assume it would be equivalent of accessing: self.__dict__['property_name'] And if those PHP rules were in python you could just write: @property def property_name(self): return self.property_name In actual python though, that would infinitely recurse.
    - arkh 2y ago
      Or if they could follow Godot syntax: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#properties-setters-and-getters https://docs.godotengine.org/en/stable/tutorials/scripting/g... var milliseconds: int = 0 var seconds: int: get: return milliseconds / 1000 set(value): milliseconds = value * 1000
LeftHandPath 2y ago
I went to look at array accessor overloading today and saw “Property Hooks” in the sidebar (under “Classes and Objects”). I didn’t know what they were, so I clicked. I was bewildered that I had never run into them before, used them in my own code, or seen them used by others. Come to find out they’ve only been around for about a day! Reminds me of some of the lovely expressibility and syntactic sugar that’s pulled me to other languages lately. Glad to see it make its way into PHP.
- 9dev 2y ago
  The next thing I would love to see adapted would by Python—style array access: $foo[1:-3:2] Instead of the usual array functions, which could stick around for BC. That would be amazing
hasnain99 2y ago
I don't Use Php but I think learning Php its better than to learn Typscript
that_guy_iain 2y ago
The breaking changes section doesn’t even mention they changed error handling in methods that haven’t been change for 20 years.
shikck200 2y ago
Looks like PHP is going even further towards Java. I really loath getters/setters with passion. I really wish PHP instead focused on getting some sort of concurrency builtin and proper unicode string literals. That should be the main focus, instead of copying various features from Java.
- 9dev 2y ago
  Look at it this way: getters/setters are the only conceivable way Laravel could ever get something like static analysability, and I wouldn’t call that framework particularly Javaian. What they do is make a whole sleuth of magic code actually discoverable and understandable, but you’ll never have to use them if you don’t want to. And even if a library under the hood implements a getter, all you’ll see of that is $foo->bar. There really have been both more invasive and more Java-style features in the past than this one.
  - shikck200 2y ago
    I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core. > but you’ll never have to use them But i do. I now cant tell if im accessing a property or a getter. With custom functions (like getFoo()) it was annoying, but still obvious, now its just magic and library authors will 100% start to abuse this feature allover.
    - 9dev 2y ago
      > I now cant tell if im accessing a property or a getter. But you never could have been sure for the last 20-ish years either? What if my library you're using (and you can be certain at least one of them does) includes a class like this: class Foo { public function __get($prop) { return match ($prop) { 'bar' => $this->doSomeHeaveIoOp(), 'baz' => query_db() default => throw new RuntimeError('Invalid property ' . $prop) }; } } The difference to a proper getter is that you never knew Foo supported the virtual properties "bar" and "baz"; the only chance you'd have was if I added doc comments, or a note in the documentation; otherwise, good luck finding it in the source code. Compare to: class Foo { public string $bar { get => $this->doSomeHeaveIoOp(); } public string $baz { get => query_db(); } } This is definitely better. It is discoverable by both you and your IDE; it allows proper documentation; it is not magic, but code; it won't go out of sync with the __call handler; it allows static analysis and typing. > I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core. Without any kind of property overloading, you're missing out on a lot of API simplification that other languages have long taken for granted. You may not like it, by stuff like pandas in Python wouldn't be possible at all without heavy overloading, and I prefer a world with pandas over one without it. Ergonomics are important; not writing tons of useless boilerplate code is, too.
cannibalXxx 2y ago
even though it's a much criticized language I still build my applications using it. for example the site https://chat-to.dev https://chat-to.dev was written entirely in php
justinclift 2y ago
Did they skip 8.4.0 and just go to 8.4.1 directly?
- ainiriand 2y ago
  No, they made 8.4.0 2 days ago and fixed it before the offcial release: https://php.watch/versions/8.4/releases/8.4.0 https://php.watch/versions/8.4/releases/8.4.0
arkh 2y ago
> Object API for BCMath Really good thing when doing some operations on monetary values. No need to use bc_* functions anymore it seems.
nilslindemann 2y ago
Non PHP expert here, can someone explain to me the line get => \sprintf("%s_%s", $this->languageCode, $this->countryCode); in the first code example? Is it a lambda?
- tored 2y ago
  Yes, you can read about it the rfc under "Abbreviated syntax" https://wiki.php.net/rfc/property-hooks https://wiki.php.net/rfc/property-hooks It follows the syntax of arrow functions https://www.php.net/manual/en/functions.arrow.php https://www.php.net/manual/en/functions.arrow.php
  - nilslindemann 2y ago
    Ahhh, and the backslash is the global namespace, as I just figured out: https://stackoverflow.com/questions/4790020/what-does-a-backslash-in-front-of-function-names-mean https://stackoverflow.com/questions/4790020/what-does-a-back...
deleted 2y ago
[deleted]
klaussilveira 2y ago
Once rector gets 8.4 rules out, this will be pretty awesome: https://github.com/rectorphp/rector/issues/8701 https://github.com/rectorphp/rector/issues/8701 https://github.com/nikic/PHP-Parser/commit/7b0384cdbe03431c44bff3261bea2717743a2b53#commitcomment-143390979 https://github.com/nikic/PHP-Parser/commit/7b0384cdbe03431c4...

486 points by theThree 2y ago

I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or is it better to wait for a few months and let someone else catch the early errors?

Dachande663 2y ago
The last few point releases have been very stable, so normally within a week or so. Obviously this relies on having a pretty good test suite (we run ~8,000 tests in ~60 seconds so not too bad for us).
TimWolla 2y ago
For PHP 8.3, we upgraded production during the RC phase, but were prepared to revert back to an older one by not relying on the new functionality. Docker makes this easy. As long as you do not use the new functionality, I'd claim that a new PHP version is no less stable than an older one. And on a contrary you would be missing out on some bugfixes that were deemed too risky to apply to an existing version. Disclosure: I've got a commit-bit for PHP, so we had in-house expertise to diagnose issues ourselves.
deleted 2y ago
[deleted]
edhelas 2y ago
Basically I follow Debian Stable releases and migrate all my code to it when a new version is pushed. So so far I'm on 8.2. It also often fit with the current Laravel version (11).
DaiPlusPlus 2y ago
> how long do you wait before migrating to higher version of PHP? I still have a PHP5 project that somehow still runs.
bawolff 2y ago
Wikipedia is still on php 7.4.33 so don't feel too bad if you are behind.
- inglor_cz 2y ago
  8.2 and 8.3, respectively. I enjoy the PHP 8 new features such as named arguments, constructor arguments promotion and nullsafe operators. Made my new code a lot more readable. I am not that sure about 8.4 yet, though the new array_ functions and new DOM look interesting.
- Cthulhu_ 2y ago
  For a project like Wikipedia, stability and continuity are far more important than latest and greatest feature support; in fact, there's an argument to be made to avoid newer language features to ensure consistency, that is, if new features are used, they should be used everywhere at once. Else you end up with frankenstein code where every file could use a different style.
  - inglor_cz 2y ago
    "Else you end up with frankenstein code where every file could use a different style." Yeah, this is a huge problem, but also, in the long run, inevitable. Plenty of Kernighan & Ritchie C code still out there...
    - wbl 2y ago
      Almost none: ANSI was over 30 years ago and enough of an improvement people switched. If you mean C89 then yes, loads of it.
      - skissane 2y ago
        It helps there are automated tools for converting old style K&R function declarations to the new ANSI/ISO style, like protoize. But K&R C is now so dated, protoize was removed from GCC 4.5 and onwards. When (in a bout of idiosyncrasy) I wanted to convert some ancient K&R C to new style a couple of years back, I ended up putting GCC 4.4 in a Docker container to make it easier: https://github.com/skissane/protoize https://github.com/skissane/protoize
jspaetzel 2y ago
I usually wait 6mo to a year in order for composer dependencies I use to get updated. Then its usually a trivial upgrade. I've upgraded sooner before for simpler projects though and things are usually pretty stable upon release.
dubcanada 2y ago
I wait one version, I’ll upgrade to 8.3 now and 8.4 when 8.5 is out.
pilif 2y ago
We start making sure our application runs on the next version around the time Beta 1 comes out. We upgrade the development environment around the time when our tooling (phpstan, cs-fixer) runs on the next version, but doesn't necessarily support new language features. We upgrade the production environment when our tooling supports most of the new language features and at least all of the ones we want to make use of. This usually happens within 3-6 months of the release. By that time the version has stabilized enough to be safe for production use.
kugelblitz 2y ago
Solo Dev on my own PHP project since 14 years. I wait 1-3 months, but then update. It used to take way longer, because Amazon's Elastic Beanstalk platform would take longer to update, but I've now changed to Platform.sh and the transition should be easier. It has been very backward-compatible (i.e. stuff that works in 8.n also works in 8.n+1; and unless you use exotic functions or are relying on special functionality, it should work for you, too). Once I'm at 8.4, I would slowly update the code / syntax with rector and the assistance of phpstan. For framework updates I wait 1-2 patch versions before updating, because of composer dependency problems and sometimes bugs do still find themselves into new releases (e.g. I would wait at least until Symfony 7.2.1 before upgrading from Symfony 7.1.x).
stronglikedan 2y ago
I wait until I need a new feature, or if there's a security issue. I still have PHP 5 apps in production.
- crowcroft 2y ago
  Didn't PHP 5 stop getting security updates more six or seven years ago? I guess depending on the app that might not really matter, but that seems like it could be an issue at some point.
  - giraffe_lady 2y ago
    There's an entire ecosystem of companies doing support and proprietary security patches and even framework-bearing polyfills for php 5. So much of the web runs on php 5 that is never ever going to be updated. It's a mini-industry unto itself. The licensing is on the order of thousands or low tens of thousands per year. Worth it for a 40-person business that has a 20-year-old legacy codebase supporting a few million dollars a year revenue. It's not what we think of as a standard "tech" company but it describes an absolutely ridiculous number of businesses.
artificialLimbs 2y ago
We’re still on 7.4 at my mid co. =|
eamann 2y ago
I'm just waiting for the official PHP Docker images to bump their updates ... which should be any time now.
ransom1538 2y ago
We leave it on staging for about 4 months, scan logs etc. If there is no complaints from qa or devs we roll it out.
gog 2y ago
Usually the release is fine, but dependencies can be lacking in proper support/testing of the newer versions, so it takes a couple of months. Also external tooling, like for example NewRelic extension, takes some time to release a version that supports the new release.

mg 2y ago

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.

aedis 2y ago
Don't forget Laravel for PHP.
- orangepanda 2y ago
  I had hoped to forget
  - BafS 2y ago
    You don't like magic? /s
- mg 2y ago
  To get to know Laravel, I forced myself to build a project with it for a few weeks and I did not like it. I found myself getting sucked in into a complex project structure and dealing with all kinds of strangeness like "artisan commands", "the autoload cache" etc. With Django, I can build a web application in a single file that has "import django" on top and take it from there: https://news.ycombinator.com/item?id=40788329 https://news.ycombinator.com/item?id=40788329
  - conradfr 2y ago
    You can do that with Symfony. https://symfony.com/doc/current/configuration/micro_kernel_trait.html https://symfony.com/doc/current/configuration/micro_kernel_t... https://symfony.com/blog/new-in-symfony-7-2-simpler-single-file-symfony-applications https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...
  - 2y ago

honzaik 2y ago

[flagged]

kyleee 2y ago
That was my first thought as well, I have never been annoyed with the explicit parens when instantiating and using a class inline

reconvene1290 2y ago

> PHP 8.4 is a major update of the PHP language. No it’s not: it’s a MINOR update.

dadver 2y ago
It can be a major update even though it's a minor version bump.
- pwdisswordfishz 2y ago
  It could have been, but isn’t. Most of those are rather small, incremental quality-of-life improvements. Nothing revolutionary.
  - theodorejb 2y ago
    I wouldn't consider all the new features small, but even many small improvements can result in a major improvement.

anttihaapala 2y ago

Oftentimes many of the significant new PHP features are to fix the shortsighted implementation in the previous ones - for example this method chaining with `new` - there was precedent already, C++ got it right well before PHP even existed and with the very same arrow operator that PHP borrowed (and so did Java and JavaScript with .), so the question is why did PHP have to get it wrong at first and for so long. Another pet peeve of me is that the global namespace is littered with these utility functions that should be easily composable or maybe be methods on the objects themselves - and looks like PHP 8.4 adds four more `array_*` functions. For comparison, Python's builtin namespace has a total of 71 functions and a couple of exception classes. PHP's builtin namespace has more functions for dealing with arrays and now 58 of those are prefixed with `array_`.

dubcanada 2y ago
The global namespace change would break everything. It’s unlikely they would ever do something like that. It’s hard to build on a language used by so many, when you can’t modify the base. Python decided to do 2.7 vs 3 and fragmented the eco system terribly.
- nneonneo 2y ago
  They could help by not adding any more cruft to the global namespace. Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the built-in function. Sure, you can’t touch the existing pile of globals, but at least stop pouring fuel on that particular fire…
  - chx 2y ago
    That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways. Surrendering the global namespace to the language is not so bad an idea.

deleted 2y ago

[deleted]

idoubtit 2y ago

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 a different meaning if it's inside a hook or outside hooks. I've used this kind of feature (getters/setters) with JS code (and with Moose/Perl decades ago), and I wasn't convinced. Plain methods are more explicit, have less cognitive charge, and are easier to extend. On the bright side, I'm glad that the language is still thriving. In 2021, I was worried when the foundation was created, especially as I read that Nikita Popov had left. He was the creator of PHP's JIT code, and at the time the only developer who could fully understand it. But it seems there was no need to worry. PHP is now longer "the elephant in the room" of web programming, but it's still a good language, with many active developers at its core.

dubcanada 2y ago
None of this is required. You can still write spaghetti code perfectly fine.
- smarkov 2y ago
  Of course it's not required but when you start pushing the boundaries of a language with the goal of achieving a clean interface, obscure features you wouldn't normally resort to become appealing. I dislike all of the magic around Laravel's Eloquent ORM - model relationships, query builder, abuse of ForwardsCalls trait, etc, but at the same time I can appreciate how "clean" it all looks once it's put together.
beberlei 2y ago
Just to set the record straight, Nikita is not the creator of the PHP JIT code, that is Dmitry and he is employed by Zend owned by Perforce working mostly on this.
- idoubtit 2y ago

ycuser2 2y ago

[flagged]

wayvey 2y ago
Wrong thread?

deleted 2y ago

[deleted]

nneonneo 2y ago

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, $filter_callback) while the older array_search is ($search_value, $array). There are literally hundreds of hits for existing, global, functions named array_find. If these are loaded from a library, they will break uses of the new built-in function in exciting ways. Yet, even with this mentioned in the RFC (https://wiki.php.net/rfc/array_find https://wiki.php.net/rfc/array_find) it seems to have been no obstacle whatsoever to its inclusion - despite the fact that the implementation is literally three lines of code. I have to question if the benefits of this global function really outweigh the benefits. PHP devs claim that other languages have these functions so PHP should too - but neglect to note that most languages don’t make them global functions (rather, they’re usually array methods or in some utility module).

kyleee 2y ago
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)
- williamdclt 2y ago
  "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)
  - asddubs 2y ago
    the answer is using a namespace
  - 2y ago

theodorejb 2y ago

Property hooks are the headline feature, but they seem like something I'd rarely use in practice. It is nice to have the option available though, in case I need to add extra logic to a property without breaking everywhere that it's accessed.

IluTov 2y ago
> A primary use case for hooks is actually to not use them, but retain the ability to do so in the future, should it become necessary. My personal motivation was always to finally put an end to the getters/setters boilerplate.

tored 2y ago

Great PHP release. Better stack traces for closures, performance improvements (always nice), HTML5 support, lazy objects and much more. Great work and a big thanks to everyone involved!

LkpPo 2y ago
IMHO the HTML5 parser is the best improvement of this version.

cbg0 2y ago

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.

ChrisMarshallNY 2y ago
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 time: https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...
- inerte 2y ago
  > With predictable results. People building and creating awesome new things? Increase in happiness and empowerment? More efficient processes and increase in productivity? New businesses being born? Wealth and value being added to society?
  - ChrisMarshallNY 2y ago
    > More efficient processes and increase in productivity I'd have to see the numbers on those ones. But I am not a "gatekeeper" type, maybe you are confusing me for one. I'm a high school dropout with a GED, and have been staring up people's noses, all my life. I just believe that any job we do, should be a good job. Build on a sand foundation, and you'd better not go too high, or Bad Things Happen.
    - deleted 2y ago
      [deleted]

vfclists 2y ago

For how many years will it get support, security and bug fixes?

philipwhiuk 2y ago
Support: 31 Dec 2026 Security: 31 Dec 2028 Bug Fixes: 31 Dec 2026 From https://www.php.net/supported-versions.php https://www.php.net/supported-versions.php
nedt 2y ago
If needed you can get LTS from Zend. They still offer security fixes for 7.2 until end of 2026 and 8.3 is supported until end of 2029. But that's just if upgrading every second or third year is too expensive to you.
- chx 2y ago
  Zend offerings are confusing. https://www.zend.com/services/php-long-term-support https://www.zend.com/services/php-long-term-support only lists 8.0 and earlier, https://www.zend.com/products/zendphp-enterprise https://www.zend.com/products/zendphp-enterprise does have a chart showing 8.3 into 2029 but once again the text only mentions 8.0. What gives?
  - nedt 2y ago
    Anything after 8.0 is not EOL. Security support for 8.1 is still provided by PHP itself until end 2025.

KRAKRISMOTT 2y ago

Are there any solid PHP WebSockets and WebRTC setups outside of Laravel?

kyleee 2y ago
Symfony? Or is this a case where Laravel has actually built out their own packages for support in these two instances?
hipadev23 2y ago
swoole makes websockets extremely easy and fast. webRTC is a beast with the STUN server needs better handled elsewhere.
josephscott 2y ago
Workerman has WebSocket support - https://manual.workerman.net/doc/en/appendices/about-websocket.html https://manual.workerman.net/doc/en/appendices/about-websock...

chx 2y ago

oooo variable-length lookbehind assertions are now supported. yay! I needed that so many times.

bwoebi 2y ago
While variable-length lookbehind is surely more comfortable to work with, I found clever usage of \K to be largely sufficient in most cases. But I agree, a great feature!

cute_boi 2y ago

I can see PHP is getting too much complex.

wvenable 2y ago
You trade complexity in source code for complexity in language. For example, property hooks will make code that currently uses other methods to accomplish that task much easier to read and write.

trevor-e 2y ago

The property access is looking a lot like Swift, particularly the `private(set)` part which I haven't seen in many other languages.

littlestymaar 2y ago

I find it pretty fascinating that what used to be a beginner-friendly language, with limited capabilities but that is very easy to get started with, has now evolve to a bloated monster full of advanced features that you can't expect to know entirely, with a complex framework and tooling ecosystem to support it. PHP lovers generally don't like acknowledge that, but the PHP we've learned back-end development two decades ago is no more and that it's now as beginner unfriendly as Java was when we picked it. It's a pity because there's nothing as beginner-friendly anymore. I think the blame is on people calling themselves “PHP developers” who never bothered learning more advanced languages after PHP and instead pushed PHP to reach parity with those, at the expanse of losing its soul.

deleted 2y ago
[deleted]
ceejayoz 2y ago
You can still write the old PHP4 way in virtually all cases. <?php echo('hello world'); ?> works fine. I've done so periodically, and every time I go "this sucks, gimme the tooling".
- littlestymaar 2y ago
  Sure, and I'm still using PHP every once in a while for personal needs (I have a handful of small personal websites built this way: PHP has this insanely cool capability of being just a scripting language for a basic dynamic website). What's sad is that it's not how people use and teach PHP today. PHP's magic really is that you can write small scripts super easily to do small tasks, but somehow most PHP developers insist that “no PHP isn't for building small scripts” but “a real, professional back end language ready for mission critical enterprise requirements blah blah blah”, because surely that make them sound more serious as programmers, missing the point entirely… (And sorry to all insecure PHP programmers out there, but for serious stuff using PHP is still equivalent to coding with handcuffs and you should really learn a second programming language at last because being a one trick poney really isn't as cool as you think it is).
2y ago

acabal 2y ago

I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. 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!

Xeoncross 2y ago
I'm curious, why do you like getters and setters? I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life. It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that perhaps we shouldn't be doing this.
- munk-a 2y ago
  I've always been a fan because if a property turns from a simple value to a more complex interaction that might involve DB operations or other side effects then if a getter is in place you can modify the logic without needing to update widespread code.
  - hamandcheese 2y ago
    If you are replacing a performant property with a slow network call, you are being negligent if you aren't reviewing all the callers to make sure that is okay.
    - hparadiz 2y ago
      In a typical ORM when you do say $Model->DateTime = 1732046457; the __set is actually checking the value and seeing oh it's an integer. Treat this as a unix timestamp. But when you run save() the query is actually converting that to a Y-m-d H:i:s (for MySQL/MariaDB). This doesn't actually happen until you run save() when it makes the query and runs the network call. Most of that time it's actually storing everything in memory. But you might want to support string date times and the PHP object DateTime as well. So a typical well designed ORM converts multiple PHP types into a SQL string for saving. That's what the historical __set and __get are all about. This is called "mapping" by most ORMs and a very well designed modern one like Doctrine will actually have mappings for different SQL storage engines available. Obviously it also has to handle the reverse.

PaulHoule 2y ago

That “public private(set)” boggles my mind. Why not “readonly public”?

wvenable 2y ago
Readonly might have different semantics (as it does in C#). Readonly has been discussed but it wasn't part of the property hooks RFC and is a separate issue/feature. This is just a natural consequence of having private setters.
bwoebi 2y ago
readonly is rather a misnomer for "writeonce" in PHP. And as such it also disallows repeated assignment in class scope, while private(set) has no such restriction.

radicalriddler 2y ago

The new Dom stuff looks really cool. I had to work with the previous functions a couple months ago and it was terrible. New API looks nice.

TheRealPomax 2y ago

Standards compliance for HTML is huge. Hopefully everyone switches to it ASAP.

dmsnell 2y ago
DOM\HTMLDocument is a huge boon. Niels Dosche incorporated lexbor into PHP to do so, and it maintains the same interface as DOMDocument once it’s instantiated. In case people aren’t aware, DOMDocument is dangerous. You can’t parse HTML with an XML parser; so everyone currently using DOMDocument for HTML would benefit by replacing that with DOM\HTMLDocument immediately, eliminating both security and corruption issues. Have you tried using an HTML parser?

dzonga 2y ago

[dead]

bornfreddy 2y ago

Am I the only one excited about bcmath objects? Not so much because of arithmetic operators, but mostly because now we can do data types checks without resorting to wrapper classes. Nice!

eurleif 2y ago

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 relevant hook. This is true for all hooks on the same property. This includes, for example, writing to a property from the get hook; that will write to the backing value, bypassing the set hook. A normal property has a stored “backing value” that is part of the object, and part of the memory layout of the class. However, if a property has at least one hook, and none of them make use of $this->[propertyName], then no backing value will be created and there will be no data stored in the object automatically (just as if there were no property, just methods). Such properties are known as “virtual properties,” as they have no materialized stored value. Be aware, the detection logic works on $this->[propertyName] directly at compile time, not on dynamic forms of it like $prop = 'beep'; $this->$prop. That will not trigger a backing value. Feels like too much magic to me that a property access can mean different things depending on context, but I'm not a PHP user, so I don't get a vote.

tail_exchange 2y ago
I'm also not a php developer, but I agree. This seems like a huge footgun. I've never been a fan of this kind of magic, and I wonder how other languages deal with this case.
- crimsonnoodle58 2y ago
  Well in python I assume it would be equivalent of accessing: self.__dict__['property_name'] And if those PHP rules were in python you could just write: @property def property_name(self): return self.property_name In actual python though, that would infinitely recurse.
  - arkh 2y ago
    Or if they could follow Godot syntax: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#properties-setters-and-getters https://docs.godotengine.org/en/stable/tutorials/scripting/g... var milliseconds: int = 0 var seconds: int: get: return milliseconds / 1000 set(value): milliseconds = value * 1000

LeftHandPath 2y ago

I went to look at array accessor overloading today and saw “Property Hooks” in the sidebar (under “Classes and Objects”). I didn’t know what they were, so I clicked. I was bewildered that I had never run into them before, used them in my own code, or seen them used by others. Come to find out they’ve only been around for about a day! Reminds me of some of the lovely expressibility and syntactic sugar that’s pulled me to other languages lately. Glad to see it make its way into PHP.

9dev 2y ago
The next thing I would love to see adapted would by Python—style array access: $foo[1:-3:2] Instead of the usual array functions, which could stick around for BC. That would be amazing

hasnain99 2y ago

I don't Use Php but I think learning Php its better than to learn Typscript

that_guy_iain 2y ago

The breaking changes section doesn’t even mention they changed error handling in methods that haven’t been change for 20 years.

shikck200 2y ago

Looks like PHP is going even further towards Java. I really loath getters/setters with passion. I really wish PHP instead focused on getting some sort of concurrency builtin and proper unicode string literals. That should be the main focus, instead of copying various features from Java.

9dev 2y ago
Look at it this way: getters/setters are the only conceivable way Laravel could ever get something like static analysability, and I wouldn’t call that framework particularly Javaian. What they do is make a whole sleuth of magic code actually discoverable and understandable, but you’ll never have to use them if you don’t want to. And even if a library under the hood implements a getter, all you’ll see of that is $foo->bar. There really have been both more invasive and more Java-style features in the past than this one.
- shikck200 2y ago
  I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core. > but you’ll never have to use them But i do. I now cant tell if im accessing a property or a getter. With custom functions (like getFoo()) it was annoying, but still obvious, now its just magic and library authors will 100% start to abuse this feature allover.
  - 9dev 2y ago
    > I now cant tell if im accessing a property or a getter. But you never could have been sure for the last 20-ish years either? What if my library you're using (and you can be certain at least one of them does) includes a class like this: class Foo { public function __get($prop) { return match ($prop) { 'bar' => $this->doSomeHeaveIoOp(), 'baz' => query_db() default => throw new RuntimeError('Invalid property ' . $prop) }; } } The difference to a proper getter is that you never knew Foo supported the virtual properties "bar" and "baz"; the only chance you'd have was if I added doc comments, or a note in the documentation; otherwise, good luck finding it in the source code. Compare to: class Foo { public string $bar { get => $this->doSomeHeaveIoOp(); } public string $baz { get => query_db(); } } This is definitely better. It is discoverable by both you and your IDE; it allows proper documentation; it is not magic, but code; it won't go out of sync with the __call handler; it allows static analysis and typing. > I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core. Without any kind of property overloading, you're missing out on a lot of API simplification that other languages have long taken for granted. You may not like it, by stuff like pandas in Python wouldn't be possible at all without heavy overloading, and I prefer a world with pandas over one without it. Ergonomics are important; not writing tons of useless boilerplate code is, too.

cannibalXxx 2y ago

even though it's a much criticized language I still build my applications using it. for example the site https://chat-to.dev https://chat-to.dev was written entirely in php

justinclift 2y ago

Did they skip 8.4.0 and just go to 8.4.1 directly?

ainiriand 2y ago
No, they made 8.4.0 2 days ago and fixed it before the offcial release: https://php.watch/versions/8.4/releases/8.4.0 https://php.watch/versions/8.4/releases/8.4.0

arkh 2y ago

> Object API for BCMath Really good thing when doing some operations on monetary values. No need to use bc_* functions anymore it seems.

nilslindemann 2y ago

Non PHP expert here, can someone explain to me the line get => \sprintf("%s_%s", $this->languageCode, $this->countryCode); in the first code example? Is it a lambda?

tored 2y ago
Yes, you can read about it the rfc under "Abbreviated syntax" https://wiki.php.net/rfc/property-hooks https://wiki.php.net/rfc/property-hooks It follows the syntax of arrow functions https://www.php.net/manual/en/functions.arrow.php https://www.php.net/manual/en/functions.arrow.php
- nilslindemann 2y ago
  Ahhh, and the backslash is the global namespace, as I just figured out: https://stackoverflow.com/questions/4790020/what-does-a-backslash-in-front-of-function-names-mean https://stackoverflow.com/questions/4790020/what-does-a-back...

deleted 2y ago

[deleted]

klaussilveira 2y ago

Once rector gets 8.4 rules out, this will be pretty awesome: https://github.com/rectorphp/rector/issues/8701 https://github.com/rectorphp/rector/issues/8701 https://github.com/nikic/PHP-Parser/commit/7b0384cdbe03431c44bff3261bea2717743a2b53#commitcomment-143390979 https://github.com/nikic/PHP-Parser/commit/7b0384cdbe03431c4...