[HN Gopher] PHP 8.4
___________________________________________________________________
PHP 8.4
Author : theThree
Score : 323 points
Date : 2024-11-21 09:56 UTC (13 hours ago)
(HTM) web link (www.php.net)
(TXT) w3m dump (www.php.net)
| inglor_cz wrote:
| 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 wrote:
| 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 wrote:
| 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.
| edhelas wrote:
| 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 wrote:
| > how long do you wait before migrating to higher version of
| PHP?
|
| I still have a PHP5 project that somehow still runs.
| bawolff wrote:
| Wikipedia is still on php 7.4.33 so don't feel too bad if you
| are behind.
| inglor_cz wrote:
| 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_ wrote:
| 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 wrote:
| "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 wrote:
| Almost none: ANSI was over 30 years ago and enough of an
| improvement people switched. If you mean C89 then yes,
| loads of it.
| jspaetzel wrote:
| 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 wrote:
| I wait one version, I'll upgrade to 8.3 now and 8.4 when 8.5 is
| out.
| pilif wrote:
| 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 wrote:
| 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 wrote:
| I wait until I need a new feature, or if there's a security
| issue. I still have PHP 5 apps in production.
| crowcroft wrote:
| 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 wrote:
| 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 wrote:
| We're still on 7.4 at my mid co. =|
| eamann wrote:
| I'm just waiting for the official PHP Docker images to bump
| their updates ... which should be any time now.
| mg wrote:
| 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 wrote:
| Don't forget Laravel for PHP.
| orangepanda wrote:
| I had hoped to forget
| BafS wrote:
| You don't like magic? /s
| mg wrote:
| 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
| conradfr wrote:
| You can do that with Symfony.
|
| https://symfony.com/doc/current/configuration/micro_kernel_
| t...
|
| https://symfony.com/blog/new-in-symfony-7-2-simpler-
| single-f...
| jonwinstanley wrote:
| Laravel is excellent for building a website, for smaller
| projects there are simpler tools and frameworks
| ognarb wrote:
| I much prefer Symfony, but that's mainly because it's the
| framework I started with.
| bojan wrote:
| I was forced to move from Symfony to Laravel and I really
| dislike it. This experience seems to be very common.
| notpushkin wrote:
| > Reload page, see changes.
|
| This should work in Python, too. With Django, I think you need
| to use https://pypi.org/project/django-browser-reload/, and
| rith most other frameworks / WSGI servers just try adding
| --reload flag.
|
| Edit: Django should wor out of rhe box actually - that package
| is for refreshing the page in browser.
|
| > Easy to deploy. Upload files, done.
|
| I can see the appeal, but generally you'd want to avoid that
| (for anything other than quick prototypes, maybe). Set up a CI,
| push to deploy. This goes for modern PHP as well.
|
| If you want something simple to deploy webapps and know a
| little Docker, I've built a deployment tool you can run on your
| own VPS: https://lunni.dev/. (Feel free to reach out if you
| need any help!)
| mg wrote:
| There are of course ways to get "reload page, see results" to
| work even with Python. After all, computers are touring
| complete.
|
| But in PHP you have it out of the box. Faster, with less
| complexity and less resource consumption. And you can use the
| same setup in development as you can use in production.
| notpushkin wrote:
| Maybe I'm missing something, but PHP is not more efficient
| in that regard.
|
| When you load a Python page, it is served by an in-memory
| process. If code is updated, the process is restarted,
| parsing the code and initialising the application, but it
| is done only once.
|
| When you load a PHP page, it parses the code and
| initializes the app _for each request_. It then tears
| everything down after the request. There are less wasteful
| ways (most recent are app servers, just like in Python or
| other langs), but I 'm not sure if those are widely used in
| local development. Even then, it's same as Python, Node or
| pretty much anything else.
|
| And of course, I'm not trying to diss on PHP here - it's
| gotten pretty good recently. But reload on change is built
| in pretty much every app framework nowadays. It works out
| of the box and is negligibly fast. It's not a good point to
| compare.
| mg wrote:
| In my experience:
|
| PHP is always blazing fast, with no additional setup to
| make "Reload page, see results" work.
|
| Python needs additional setup. Either by monitoring the
| filesystem and pessimistically recompiling the
| application every time a file changes. Causing resource
| consumption every time you hit save in your editor. Or by
| having the web workers that serve the requests die after
| 1s of inactivity or so. Which makes the next pageview
| slow again, even if no code changed.
|
| I think PHP's advantage is because of 3 things:
|
| 1: Recompiling changed files is built in.
|
| 2: With PHP you can set your project up in a way that
| only the code necessary to answer a single request is
| updated. With Python and Django, all the code for all
| requests is updated and even code paths that are actually
| never used.
|
| 3: PHP keeps each file compiled to bytecode in memory and
| only recompiles files that have been changed. Although
| you might accomplish something similar in Python if you
| let it pollute your filesystem with cached bytecode
| files.
| graemep wrote:
| > When you load a PHP page, it parses the code and
| initializes the app for each request. It then tears
| everything down after the request. There are less
| wasteful ways (most recent are app servers, just like in
| Python or other langs), but I'm not sure if those are
| widely used in local development.
|
| There are things like opcode caches that make PHP more
| efficient transparently, while still feeling to the
| developer like a reload each time.
|
| There are reliability and development advantages to
| starting each request from scratch. NO leaks, no state
| you need worry about.
|
| PHP is very much like serverless.
| mobilio wrote:
| This is true when you call PHP using CGI or CLI. Then
| opcode is build, running and thrown away.
|
| But when u are using FCGI or PHP-FPM then you have
| running process where opcode is cached except on first
| request where opcode cache is build.
| hipadev23 wrote:
| With standard opcaching and jit enabled, the reparsing
| step doesn't happen.
|
| Initializes for each request is standard with php-fpm,
| but swoole/workerman/etc are rapidly gaining popularity
| and run as a more typical app server with coroutines.
| alternatex wrote:
| PHP fast? Compared to all popular web frameworks it's quite low
| in the pecking order when it comes to performance.
| dubcanada wrote:
| Not sure where you got that from. It's equally if not faster
| then python, faster then Java, slower then compiled language,
| faster then ruby. Loses to NodeJS most of the time.
|
| But who cares, we are literally talking millisecond
| differences between them all. Throw a reverse proxy, DB into
| the mix and a few packages and they are all slow.
| askonomm wrote:
| And if we actually want to talk speed, PHP with something
| like Swoole or ReactPHP is many times even faster[0] than
| the already fast regular PHP.
|
| [0]: https://medium.com/@dimdev/9-php-runtimes-performance-
| benchm...
| biorach wrote:
| > faster then Java
|
| You sure about that? Not what I would have expected.
| Source?
| dubcanada wrote:
| My point was less about the leaderboards and more about
| it being pointless comparison. But I was looking at
| https://web-frameworks-
| benchmark.netlify.app/result?l=java,p... though I don't
| really know what people consider "best benchmark" for raw
| vs raw. Once you start throwing in
| apache/nginx/proxies/what ever it really starts to
| balance itself.
| sneed_chucker wrote:
| Definitely not faster than Java if we're talking single
| thread performance.
| JodieBenitez wrote:
| > - Easy to deploy: Upload files, done.
|
| Sure, it works for simple/less important cases. But it also
| means that your application code is inconsistent while the
| files are uploading.
|
| Stop your service, upload the files, start the service: safer.
|
| For a Django app you would upload files and ask Gunicorn to
| graceful reload... similar, just cleaner.
| kijin wrote:
| You can use the same strategy with PHP. Preload all your
| scripts in opcache. Once you're done making changes, reset
| your opcache.
|
| In practice, any serious project is likely to be version-
| controlled. Git pull is generally fast enough that it behaves
| like an atomic change. (By default, opcache will not reload a
| file that's less than 2 seconds old.)
| JodieBenitez wrote:
| I'm pretty sure many PHP dev don't know about OPCache. Many
| of my colleagues don't know for sure. My point is "be aware
| of the state of your app code and what you execute", and so
| be aware of the shortcomings of this deployment "strategy".
| It's sure perfectly fine and easy for small apps / low
| traffic / not critical apps. I just want to point that it's
| not inherently good enough and definitely not the universal
| way to deploy a PHP app.
|
| Git pull to deploy is something I avoid.
| lenlorijn wrote:
| Most PHP apps use a deployment method where a symlink gets
| set to a directory with a new version of the code. Because of
| how opcache works this has no impact on running requests,
| while new requests get handled with the new code.
| JodieBenitez wrote:
| Yes, my point really... it's really not "just upload files"
| like it's 1997.
| jiehong wrote:
| Python's packaging and dependencies system is lacking, but
| trying to get better. But too many choices not always
| compatible nor working perfectly right (should you use pip,
| poetry or pipenv? Well, you see...)
|
| How's php's?
| BadBadJellyBean wrote:
| > Python's packaging and dependencies system is lacking
|
| It is? I never had problems with poetry. Though I agree that
| there are mroe options than necessary.
| sigmonsays wrote:
| That's a wild perspective.
|
| Python has the worst packaging ecosystem i've ever seen
| taskforcegemini wrote:
| worse than javascript?
| steve918 wrote:
| Python's packaging system is worse, but Javascripts
| packages / standard libraries are far worse than Python.
|
| 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.
| pluc wrote:
| They just added extension support to packagist, so composer
| looks like a pretty healthy ecosystem that's officially
| supported.
|
| https://thephp.foundation/blog/2024/11/19/pie-pre-release/
| cess11 wrote:
| PHP has a rather nice type system. It also doesn't use
| whitespace as syntax, which makes it much easier to generate ad
| hoc.
|
| Slim is a pretty nice framework: https://www.slimframework.com/
| jayflux wrote:
| > Easy to deploy: Upload files, done
|
| I know people love to say this, but does anyone realistically
| make websites or web apps that way? No, not really. Even with
| PHP there are frameworks, there is a package manager, there is
| version control, and there are deployment systems.
|
| Pretending that PHP developers are uploading a .php file to a
| shared hosting server (like in 2002) to suit the narrative
| feels disingenuous to me as it doesn't align with what I see
| PHP developers doing at all.
| sjm-lbm wrote:
| .. and as soon as you stop just uploading files (which, as
| you say, nobody does), a lot of the other advantages go away
| also. Laravel and Symphony both make PHP much slower. If you
| are going to have sane routing, you're probably going to need
| to tweak your websever to behave, well, less like a web
| server. There's a decent chance you'll need to clear a cache
| after you upload your changed files if you want to actually
| see those changes.
|
| I actually like PHP a lot, and it's amazing how far it has
| come in the past 10 or so years, I just think way too many
| people assume you get the 2004-era PHP simplicity with all of
| the 2024-era PHP refinements, and you really don't. There's
| tradeoffs.
| alt227 wrote:
| >but does anyone realistically make websites or web apps that
| way?
|
| You are correct in that a lot of PHP use now is larger
| frameworks with asset compilation and cache clearing etc, but
| even when developing on large systems like that it is nice to
| sometimes be able to just manually tweak a file and refresh.
|
| For R&D and quick tests, just uploading a quick & dirty php
| file to the server is a very useful language feature to have
| IMO.
| jayflux wrote:
| > For R&D and quick tests it is a very useful language
| feature to have IMO
|
| Right, but unless you have an ftp server or quick ssh
| access and PHP isn't doing any code caching that feature
| isn't an advantage, how many developers are in that
| situation? Is this something you do?
|
| If you're running locally PHP spawns its own server which
| other runtimes have. If you're running this on a server
| you're most likely going to have app/code caching (apc Or
| opcache) switched on so you'll need to restart the server
| anyway, in which case it's not more advantageous than
| uploading a js file and restarting node.
| alt227 wrote:
| > Right, but unless you have an ftp server or quick ssh
| access
|
| These days all of that is built right into IDEs
|
| > Is this something you do?
|
| Yes. After linking my IDE to a remote location I can then
| noodle around with scripts to test whatever. The
| immediate nature of PHP means the instant you hit ctrl-s
| your changes are live online.
|
| > If you're running this on a server you're most likely
| going to have app/code caching (apc Or opcache) switched
| on so you'll need to restart the server anyway
|
| In prod yes, but in dev environments all that is switched
| off as its not needed.
| wvenable wrote:
| > I know people love to say this, but does anyone
| realistically make websites or web apps that way?
|
| In PHP, I do. In other platforms, no. My personal PHP site is
| published by a git push to the server.
| handzhiev wrote:
| I do it all the time, thank you very much. For a simple web
| app I don't even need a framework - you can literally create
| a simple files/folder structure, include files, include
| folders and get stuff done. An yeah, you can also upload the
| files by FTP. For something more complicated I'd use WP or
| Code Igniter depending on the specific project. And then you
| can again just SFTP those files to the server.
| whalesalad wrote:
| technically you can do the same thing with python, via python
| server pages =)
| fbn79 wrote:
| Node: - easy to deploy: If you dont complicate yourself, with
| cpanel or plesk hosting is just matter of copy the files. -
| Terabytes of npm packages (even too much :)) - A non bloated
| and nice language (JavaScript) - Optional type checking with
| typescript if you want. - Non blocking IO
| reconvene1290 wrote:
| > PHP 8.4 is a major update of the PHP language.
|
| No it's not: it's a MINOR update.
| dadver wrote:
| It can be a major update even though it's a minor version bump.
| pwdisswordfishz wrote:
| It could have been, but isn't. Most of those are rather
| small, incremental quality-of-life improvements. Nothing
| revolutionary.
| theodorejb wrote:
| I wouldn't consider all the new features small, but even
| many small improvements can result in a major improvement.
| anttihaapala wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nneonneo wrote:
| Suppose I want to add some new code to an old website? Or
| I want to gradually upgrade an ancient code base - twelve
| years is not so old for PHP, when ancient frameworks like
| Wordpress are still alive and kicking.
| chx wrote:
| 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.
| nneonneo wrote:
| Seriously? 2k results for array_find in PHP on GitHub: ht
| tps://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/maste
| r/app/Support/helpe..., a PHP app last updated just two
| years ago (140 stars, 63 forks) which _only_ supports PHP
| 8.x. Implementation is thoroughly incompatible with 8.4
| 's array_find.
|
| There are so many more examples. Lots of the hits are
| from codebases that have seen updates in the last few
| years. Many more are plugins or other addons for PHP
| frameworks or apps which are still widely used
| (WordPress, phpBB, etc.).
| alganet wrote:
| The example you picked:
|
| https://github.com/hawind/gdoo/blob/master/app/Support/he
| lpe...
|
| 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.
| imoverclocked wrote:
| I think the bigger issue is that these lessons have already
| been learned. However, PHP (Personal Home Page) was not
| created carefully by someone to become a fully fledged
| language. It grew into that role organically which is why it
| has so many warts in hindsight.
| lofaszvanitt wrote:
| 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?
| rty32 wrote:
| 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 it is defined in
| the standard library. You get a very confusing error and
| spend 10 minutes trying to figure if it is you or PHP that is
| hallucinating. Turns out you have been inadvertently calling
| that other user defined function. The other user may be
| completely unaware of the fact that they created a function
| with naming collision.
|
| To combat this, you need strong IDE help including static
| type checking, which is not always there for everybody. And
| it still doesn't help with cases where the user defined
| function collides with a new standard function.
|
| Most "modern" languages have very few built-in functions in
| the global namespace. Another example is Go. Correct me if I
| am wrong, but I believe there is 0 function in global
| namespace in Rust. println! exists but that's a macro. In
| other words, the example I mentioned just never happens with
| these languages.
|
| Not to mention the long list of junk you see in IDE when you
| type "array_".
|
| I guess you haven't written much MATLAB.
| nneonneo wrote:
| Rust namespaces everything in the standard library to std::
| or core::, and has a clear distinction between them.
|
| However, it does implicitly include the entirety of the
| std::prelude namespace (https://doc.rust-
| lang.org/std/prelude/index.html) into every source file, as
| well as including every macro directly exported under std::
| (including println!). This enables the unprefixed use of
| things like Result, Option, Some, Send, etc.
|
| The prelude and std:: macros are the closest thing that
| Rust has to a global namespace, and even they can be
| disabled in crates that specifically request it.
| alganet wrote:
| 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.
| rty32 wrote:
| 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.
| sam_goody wrote:
| I don't get your issue with builtin utilities.
|
| The design philosophy of PHP is to include whatever common
| methods would otherwise be in a popular library. (PHP actually
| began more as a library than as a language.) This differs from,
| eg, Python, but doesn't hurt.
|
| The decision not not to make methods on the objects, but to
| include everything in the main namespace (so array_walk instead
| of Array.walk or Array()->walk etc) is another function of the
| same philosophy. It may not fit your idea of cosmetics, but
| there is nothing wrong with it.
|
| On the other hand, I would love if PhP gained chainability
| ([].array_map.array_find()) and then the names would be a pain.
| If that ever happens there are solutions.
| askonomm wrote:
| There is a RFC on it (https://wiki.php.net/rfc/function-
| composition) which I'd love if it made it through. Until then
| Crell's FP library is a good option
| (https://github.com/Crell/fp).
| idoubtit wrote:
| 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 wrote:
| None of this is required. You can still write spaghetti code
| perfectly fine.
| smarkov wrote:
| 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 wrote:
| 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 wrote:
| Thanks for correcting me, and sorry for the error. I should
| have checked before writing.
| chx wrote:
| > Property hooks mean that some language magic will turn a
| property access into a call to methods.
|
| __get / __set was doing that already and some frameworks very
| heavily rely on those.
|
| > It implies that `$this->x` has a different meaning if it's
| inside a hook or outside hooks.
|
| this is a valid critique but hopefully hooks will be super
| short and this won't be a major issue. Indeed, if your get is
| not an arrow function -- which only allows one statement --
| then it needs a good thinking over whether this is indeed the
| best solution. Ie if your get is so complicated then perhaps a
| helper method is best and then you have get =>
| $this->foo($this->thing) and that's the only place where
| $this->thing is special.
| idoubtit wrote:
| > hopefully hooks will be super short and this won't be a
| major issue.
|
| Even if a PHP project has a policy of short hooks, I think
| hooks impede clarity. public string
| $countryCode { set (string $countryCode)
| { $this->countryCode =
| strtoupper($countryCode); $this->country =
| nameCountry($this->countryCode); }
| get => ...
|
| In this short hook, the first line of the setter obviously
| uses the underlying property. But the second line of the
| setter...
|
| Does `$this->country =` use the setter even if it's in a hook
| (but not a `country` hook)?
|
| Does reading `$this->countryCode` use the getter hook, even
| it's from a `countryCode` hook?
|
| If not, is there a way to call the `countryCode` getter from
| this setter?
|
| If quickly parsed the doc and the RFC, so I don't have
| answers (I suppose it's yes, no, no). But even if I knew how
| this code behaved, I would still think it's much more complex
| than plain methods.
| chx wrote:
| > Does `$this->country =` use the setter even if it's in a
| hook (but not a `country` hook)?
|
| To me it is obvious hooks won't use other hooks because
| that could lead to an infinite loop in a hurry
|
| > Does reading `$this->countryCode` use the getter hook,
| even it's from a `countryCode` hook?
|
| same
|
| > If not, is there a way to call the `countryCode` getter
| from this setter?
|
| There is although it's a bit tricky and not intuitive but I
| feel this falls under the "it is enough this is possible,
| there's no need for it to be easy": "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." Using dynamic properties in what should be simple
| code should be rare enough this is not a problem. It's like
| a bridge convention, the benefits vastly outweigh the
| drawbacks.
| c0wb0yc0d3r wrote:
| > Does `$this->country =` use the setter even if it's in
| a hook (but not a `country` hook)? To me it is obvious
| hooks won't use other hooks because that could lead to an
| infinite loop in a hurry
|
| I would expect hooks for properties other than
| `$this->contryCode` to be called inside of a
| `$this->contryCode` hook.
|
| Btw the docs that are linked in the post[0] seem to be
| clearer than the example in the announcement. Reads less
| ambiguously to me.
|
| [0]: https://www.php.net/manual/en/migration84.new-
| features.php#m...
| alt227 wrote:
| You are corect that the docs read much clearer. Why would
| they muddy the concept in the release post?
| patates wrote:
| > To me it is obvious hooks won't use other hooks because
| that could lead to an infinite loop in a hurry
|
| Yet in Javascript:
|
| test = { set a(x) { this.b = x }, get a() { return 2 },
| set b(x) { this.c = 10 }}
|
| Object { a: Getter & Setter, b: Setter }
|
| test.a = 10
|
| 10
|
| test
|
| Object { a: Getter & Setter, b: Setter, c: 10 }
|
| and yes it's possible to make infinite loops.
| Gabrys1 wrote:
| Why would you write such code though? If you want to store
| an underlying properly, use a differently named (and
| private) one:
|
| public string $countryCode { set (string $countryCode) {
| $this->_countryCode = strtoupper($countryCode);
| $this->country = nameCountry($this->_countryCode); }
| conradfr wrote:
| Don't you get tired of managing getters/setters in your
| entities?
| mgkimsal wrote:
| aren't you just managing them in a new syntax now?
| joshmanders wrote:
| The difference with property hooks and userland
| getter/setters is that you're now just doing
| echo $obj->prop $obj->prop = 'bar';
|
| not echo $obj->getProp();
| $obj->setProp('bar');
| cutler wrote:
| Entities, shrentities - it's all just data.
| tcfhgj wrote:
| which getters/setters?
| whalesalad wrote:
| stockholm syndrome is real
| jacobyoder wrote:
| I'd tried to put together an RFC years ago to introduce groovy-
| style accessors in PHP.
|
| $this->foo
|
| would look for a getFoo() method, and execute if it existed, or
| not if not. Felt like that was easier to reason about, fwiw,
| but I couldn't get it off the ground. Even then, there were
| multiple C#-style get/set proposals floating around, so this
| style seems to be the one more people like. Not a fan of the
| style, personally, and probably won't use these much directly
| any time soon. If it helps people maintaining libraries that I
| use to deliver code that is cleaner and more productive to
| them... I'm OK with that.
| wvenable wrote:
| I'm not a fan of that kind of magic in my languages but such
| a thing was already easily doable in PHP. You could just have
| a base class that implements __get and __set so that
| $this->foo automatically calls $this->getFoo().
| mgkimsal wrote:
| can't do that if you declare the properties on the class.
| __get only works for undefined properties.
| wvenable wrote:
| Well don't do that then. :)
| munk-a wrote:
| Or, alternatively, use `__call`
| 9dev wrote:
| _Doctor, doctor, it always hurts when I press here..._
| ok123456 wrote:
| This feature has been in C# since about 2.0, and it's been an
| overall positive. It reduces boilerplate and inconsistencies in
| different programmers doing the boiler-plate differently.
|
| It also gives static analysis tools semantic information about
| the structure of your classes. It can group pairs of methods
| that deal with the encapsulation of fields.
| brtkdotse wrote:
| My experience is that 99% of the work related to geters and
| seters is handled by the IDE
| ok123456 wrote:
| This encapsulation style for OOP is standard; the language
| should support it and not require additional design
| patterns or IDE tools.
|
| An argument could be made for adding a sigil so the class
| user knows this isn't a dumb field, but then if someone
| wants to upgrade a dumb field to this, as Python
| encourages, they would need to modify every use.
| crowcroft wrote:
| I am also in favour of the change. I would argue though that
| because it's been in C# for so long, then yes it reduces
| inconsistencies across programmers/codebases, but introducing
| it to a language as mature as PHP is now though, might not
| have the same outcome.
| ok123456 wrote:
| I used it immediately in my C# code at the time. It was a
| breath of fresh air not to have code that looked like
| "enterprise" java.
| signal11 wrote:
| It's interesting to consider the "magic" criticism in the
| context of languages like Zig, where devs actively want no
| hidden control flow. And Properties beyond simple { get; set;
| } are definitely hidden control flow.
|
| But as you said -- it's been there in C# for a while and imho
| it's a good abstraction over getters and setters. Even
| 2005-era IDEs could manage it fine, making it easy to access
| the property's get/set code, so that it wasn't really
| magical.
|
| Maybe it's a culture thing -- most C# devs use IDEs. Not sure
| what PHP devs use, but I suspect tools like PhpStorm will
| make this easy to work with somehow. Devs using no-LSP
| editors will likely have a different view.
| amerkhalid wrote:
| > Maybe it's a culture thing -- most C# devs use IDEs. Not
| sure what PHP devs use, but I suspect tools like PhpStorm
| will make this easy to work with somehow. Devs using no-LSP
| editors will likely have a different view.
|
| This is probably one of the big factors. I am also not a
| huge fan of "magic" even though I use IDE (vscode). I
| started off as a PHP dev, directly editing files on
| production server using vi. Any "magic" simply slowed me
| down.
|
| Years later, now I can simply cmd+click to anywhere in code
| but it feels a bit off to me. Perhaps, I still miss my old
| days of dev.
| neonsunset wrote:
| How do you expect properties to interact with IDEs?
|
| The arguments that C# choosing to offer features that lead
| to terser implementation always seem completely orthogonal
| to this. Behavior in property getters and setters may as
| well be completely hidden from the caller. But the standard
| expectation is that accessing and/or setting a property
| should be cheap and not involve much logic, which most of
| the code out there adheres to.
|
| (and personally I'm finding it to be a more productive
| experience than any dynamically typed language which always
| feels like stone age regardless of the environment)
| James_K wrote:
| Every step on the path to bloat is justified.
| munk-a wrote:
| 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.
| int_19h wrote:
| Properties have been in C# since the very first version. And
| those, in turn, were largely inspired by Delphi, with the
| honorable mention of Visual Basic.
| alt227 wrote:
| I agree. PHP is such a simple language to follow but now with
| these property hooks, if you dont fully understand how they
| work then the code becomes unreadable due to the magic.
|
| Worse than that, it is possible to read it wrongly which is
| going to cause many nasty headaches for amateur developers of
| the future trying to debug PHP code.
| giraffe_lady wrote:
| I wrote php exclusively only for about two years early in my
| career but have had to come back to it periodically every
| once in a while. I find it one of the most difficult
| languages to be a visitor in. The way variable, array, and
| class semantics mix can make it hard to decipher the exact
| behavior of a chunk of code. Especially if you have a mix of
| "old" procedural and modern OO php, which the projects I work
| on do.
|
| I'm not bringing this up as a particular criticism of the
| language, I think it's fine. It is also an experience I have
| with lisp, where it is fun and easy to write but hard to read
| when coming back to it after a while away. I just don't think
| php is a simple language, on several levels. The semantics
| that I mentioned, combined with the mixing of paradigms, and
| the large and inconsistent standard library. You can write
| simple php but it takes a lot of discipline.
| alt227 wrote:
| > 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 people
| regularly rewrite their entire code base multiple times to
| take advantages of the new features. Do a google search for
| guides on node programming a specific issue, and depending
| on how old it is it you will get wildly differnt approches
| and results. Popular and highly developed languages change
| often, and this will always cause issues between old and
| new.
| giraffe_lady wrote:
| 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 framework composed of a mix of libraries. Ruby and
| python aren't better languages than php or node, and
| rails and django aren't perfect, but to a large extent
| those languages avoid this problem just because everyone
| is using the same solutions.
| wbl wrote:
| T_PAAMAYIM_NEKUDOTIM, mysql_real_es ape2, parse_str, etc.
| duskwuff wrote:
| > mysql_real_escape2
|
| Blame MySQL for that name, not PHP.
|
| https://dev.mysql.com/doc/c-api/8.4/en/mysql-real-escape-
| str...
|
| (And, if you're doing modern PHP, it's just
| PDO->quote().)
| munk-a wrote:
| I'm not certain about OP's objection but for me it's less
| the function name and more the terrible history of how
| PHP tried to automatically fix SQL injection and instead
| made everything a thousand times worse. If you're not
| using bound parameters for user data you're taking a huge
| risk and making your life multitudes more difficult.
| PHP's PDO is by far the better option at this point but
| it suffers from poor enough usability that I've built my
| own wrapper for it at two different companies.
| hparadiz wrote:
| Writing a wrapper for PDO is standard operating procedure
| for various good reasons.
| wbl wrote:
| Why should I blame MySQL? It's the PHP developers that
| decided to introduce it and not change the name, plus
| have several functions that don't do the right thing as
| well.
| wvenable wrote:
| PHP has had the ability to dynamically handle properties for
| decades so this doesn't hurt readability -- in fact, it makes
| it better.
| Shorel wrote:
| I just checked the code samples from the article/post.
|
| Property hooks look awesome, they fix something that's my main
| pain point in PHP nowadays.
|
| All these getters and setters manually coded make it feel like
| Java. Just completely boring and unusable without some fancy
| IDE that types all that boilerplate.
|
| It is one great feature of C# that I'm glad PHP is adopting.
| This code is also easier to extend than the Java-like sea of
| getters and setters.
|
| (I don't consider any mention of JS code as a valid comparison,
| if anything we are better ignoring JS existence unless forced
| to do some frontend)
| munk-a wrote:
| While these are certainly a better option automatically
| generated default getters and setters have been pretty do-
| able through magic methods for a while now - and with the
| more robust reflection we now have access to they can be
| implemented in a safe manner. I'm still pretty happy to hear
| we're getting it as a baked in feature.
| klaussilveira wrote:
| I feel the opposite: this brings simplicity and pragmatism back
| to PHP. Gone are the years of bowing to the verbosity of Java,
| sacrificing a dynamic powerful language at the altar of 1995's
| OOP paradigms.
| cutler wrote:
| Seriously? Since 5.3 PHP has worshiped at the alter of Java
| OOP to the extent that writing PHP code is now an exercise in
| pseudo-Java.
| klaussilveira wrote:
| Yes, that is correct. And this release marks a point where
| the language is officially moving away from that.
| notresidenter wrote:
| This has existed for so long though, through `__get`, `__set`
| and other methods, the ArrayAccess interface, the `__call` and
| `__callStatic` methods.
|
| This way, at least, it's much more explicit. And this should
| probably only be used inside frameworks anyway, and not in
| "user-land" code.
| reaperducer wrote:
| _The two new language features bring a higher language
| complexity for dubious gains._
|
| For a long time now, PHP has been on a trajectory of trying to
| be everything to everyone, constantly bolting on features from
| every language that happens to drift by.
|
| My observation has been that the people who are deeply invested
| in PHP are tired of being hazed online for using a "toy"
| language, so they're trying to adopt all of the complexity and
| problems of other languages, rather than just keeping things
| simple, which is what used to be PHP's primary strength.
| nneonneo wrote:
| 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) 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 wrote:
| 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 wrote:
| "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)
| nodogoto wrote:
| You can't redefine functions in PHP.
| mklepaczewski wrote:
| There are extensions which allow you to redefine even
| constants.
| asddubs wrote:
| the answer is using a namespace
| someothherguyy wrote:
| > `array_find` doesn't have the same signature and
| semantics than the new global then you're screwed
|
| Screwed? Just rename or move the function to a namespace in
| an IDE and it will update all your references?
| mklepaczewski wrote:
| Your IDE should help you with the argument order if that's an
| issue for you. It has never been a problem for me and I don't
| understand the argument. I get that it might be confusing the
| few first times you use these functions, but if you use them
| every day you just remember the argument order.
|
| The backward compatibility section found only 200-ish projects
| where array_find() was defined in global name space. For me
| that's a small price to pay for introducing the new function,
| and refactoring should BE easy when upgrading a project to PHP
| 8.4.
|
| Adding array_find() to a namespace would be inconsistent. All
| other array_*() functions are global.
| theodorejb wrote:
| 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 wrote:
| > 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 wrote:
| 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!
| cbg0 wrote:
| 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 wrote:
| 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/programmin...
| inerte wrote:
| > 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 wrote:
| _> 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.
| grey-area wrote:
| This varies by domain of course, but on the web (PHP's
| domain), the language in greatest use nowadays by
| professional programmers is....Javascript.
| omnimus wrote:
| Because its hard requirement. Its not the case at all on
| backend.
| grey-area wrote:
| No, I'm talking about voluntary use of frameworks like
| react to create websites.
|
| The front end can have very little js and still be fully
| functional (like this website for example).
| 7bit wrote:
| What a condescending point of view.
| owenpalmer wrote:
| I don't think OP was trying to be condescending. Even if
| they were, they're still right. A lot of modern languages
| are designed with bad programmers in mind.
| ChrisMarshallNY wrote:
| Wasn't trying to be, but it's my experience that people
| will deliberately assume the very worst intentions,
| behind whatever I write, so it's a losing proposition,
| trying to be circumspect.
|
| I am, however, pretty against selling crap. If people pay
| for my work, or even if they don't (most work I do, these
| days, is free), they have the right to expect that I did
| good work.
|
| I do run into quite a few folks that write crap, know
| they write crap, but don't care, and expect people to pay
| top dollar for their crap.
|
| If that's a "condescending" attitude, then guilty as
| charged.
| rty32 wrote:
| To be honest, it's a pattern I see under every PHP
| thread:
|
| (Neutral) PHP news -> PHP bad -> PHP not bad
|
| Even if people didn't actually say "PHP bad"
| ChrisMarshallNY wrote:
| I use PHP for my backend work. I am not an outstanding
| PHProgrammer, because, quite frankly, I don't like the
| language, but I'm good enough to write fairly robust,
| secure, and performant backends.
|
| I just hold my nose, write my backend, then get back to
| my frontend, as soon as possible.
| munk-a wrote:
| One thing I'd like to highlight though is that there were
| mountains of terrible advice out there around PHP from
| novices who had figured out a way to make things work -
| around the time of PHP 5.3 the community ran an ambitious
| initiative to crawl through sites like Stack Overflow and
| replace bad answers with correct ones. The community
| realized how dangerous it was for novices and how much
| all the bad advice was hurting the reputation of the
| language and they took decisive action to fix it.
|
| Separately, IMO, languages should always be designed with
| bad programmers in mind - good programmers are going to
| figure out the right way to do things in any language but
| bad programmers are going to fire off every foot gun they
| can find. PHP has made efforts to remove or de-emphasize
| foot guns and it has evolved into a much safer tool to
| give someone.
| rty32 wrote:
| Which part is condescending? Maybe spell that out?
|
| From what I can see it's some pretty unbiased conclusion
| that's quite reflective of the truth.
| lesuorac wrote:
| I dunno, we just about got rid of the whole "cosmic rays"
| discussions for computers and finally are getting realistic
| about the bugs that occur in computers are from bad C code
| and bad hardware. Neither of those things are easy to use and
| they have done probably more damage than crappy php code
| does.
| dctoedt wrote:
| > _more airbags, for the bad code_
|
| Great metaphor. I might steal it for some model contract
| terms I'm doing (for an expanded version of my contract-
| drafting course materials). I'd been thinking of
| "guardrails," but "airbags" is far better.
| vfclists wrote:
| For how many years will it get support, security and bug fixes?
| philipwhiuk wrote:
| Support: 31 Dec 2026
|
| Security: 31 Dec 2028
|
| Bug Fixes: 31 Dec 2026
|
| From https://www.php.net/supported-versions.php
| KRAKRISMOTT wrote:
| Are there any solid PHP WebSockets and WebRTC setups outside of
| Laravel?
| kyleee wrote:
| Symfony? Or is this a case where Laravel has actually built out
| their own packages for support in these two instances?
| hipadev23 wrote:
| swoole makes websockets extremely easy and fast.
|
| webRTC is a beast with the STUN server needs better handled
| elsewhere.
| chx wrote:
| oooo
|
| variable-length lookbehind assertions are now supported.
|
| yay! I needed that so many times.
| cute_boi wrote:
| I can see PHP is getting too much complex.
| wvenable wrote:
| 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 wrote:
| The property access is looking a lot like Swift, particularly the
| `private(set)` part which I haven't seen in many other languages.
| littlestymaar wrote:
| 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.
| ceejayoz wrote:
| 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".
| NackerHughes wrote:
| PHP is still definitely a beginner-friendly language that is
| still very easy to get started with. Setup is as trivial as it
| always has been, copy a .php file onto a server and you're good
| to go. No complicated frameworks or "deployment process" needed
| if you don't want them (and most people don't need them).
|
| The difference between it and Java is you're not forced into
| the ClassObjectGetterSetterPropertyHookFactoryBean paradigm
| with PHP. You can continue to write concise, simple, elegant
| scripts that read from top to bottom and serve one page and
| serve it well. You don't _have_ to use any of these crazy
| newfangled features - I, for one, will be using none of them,
| and will be sticking to my if-else blocks and nested for loops
| that will be easy to read and grok when I (or someone else!)
| come back to the code two months down the line.
| acabal wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hamandcheese wrote:
| 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.
| hparadiz wrote:
| 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 in $record->isDirty
| will run isDirty() under the hood for you. All these
| things can be documented with PHPDoc and static analyzers
| handle it just fine.
| wvenable wrote:
| A method is supposed to be an action and a property is
| supposed to be data. So I don't see the desire to
| disguise setting data as a "setting method" rather than
| using the syntax of assignment.
| hamandcheese wrote:
| > A method is supposed to be an action and a property is
| supposed to be data.
|
| I agree! That's why it's wild to allow a setter to do
| literally anything.
|
| You aren't just setting a property, there is a conversion
| happening under the hood.
|
| And the reason I hate it is that code that appears to be
| infallible, isn't. It can have arbitrary side effects,
| raise exceptions, have unbounded runtime, etc.
| wvenable wrote:
| It's abstraction. Your not supposed to care that the
| setter is doing anything. The class is providing you an
| interface -- what it does with that interface is not your
| concern. I hate to quote Alan Kay but all objects should
| just respond to messages. Whether that message
| corresponds to a method or a property is pure semantics.
|
| I sometimes use getters and setters to provide backwards
| compatibility. What was just maybe a simple data field a
| decade ago doesn't even exist anymore because some major
| system has changed and we aren't rewriting every single
| application when we can provide the values that they need
| easily enough.
|
| If you know that setters exist then you already know that
| the code can do more. It's not a huge mental leap from
| property setting to method calls. You should never assume
| anything is infallible.
| acabal wrote:
| They are very useful when modeling CRUD-dy objects, because
| you can lazy-load infrequently-accessed child object using
| getters.
|
| It makes for a cleaner OOP-y interface in which the caller
| only cares about _actually exposed properties_ and not
| _methods to get and manipulate hidden properties_.
|
| IMHO using properties directly is a much more natural way to
| talk about objects, than having a bunch of methods to get
| properties. Getters and setters also help ensure that methods
| are only for _changing_ an object 's state, not _getting_ an
| object 's state. For example: class User{
| public ForumsPost $LastForumsPost{ get{
| if(!isset($this->LastForumsPost)){
| $this->LastForumsPost = <get from database...>;
| } // Return the cached property so we
| don't keep hitting the database. return
| $this->LastForumsPost; } } }
| print($user->LastForumsPost->Title);
| print($user->LastForumsPost->PostId); // instead
| of... print(($user->GetLastForumsPost())->Title);
| print(($user->GetLastForumsPost())->PostId);
| hamandcheese wrote:
| I do not see any advantage here. All I see (or rather, what
| can't be seen) is hidden control flow. For what? To save a
| few characters?
| acabal wrote:
| It's a matter of OOP modeling. Object methods are better
| reserved for performing actions with side effects, or
| complex logic or calculations, and not for getting state
| or simply setting public properties; and as a caller, I
| don't really care about the implementation details of (in
| my above example) getting the last forums post, I just
| care that it's a property I can access. (Maybe it came
| from a cache and not the database? Maybe it was set
| earlier in the script? I don't care.)
|
| Putting it behind a getter doesn't "hide" control flow.
| It just makes for a cleaner interface from the caller's
| perspective.
|
| FWIW, I almost never use setters. Getters are are much
| more useful, especially for lazy-loading basic
| properties.
| Xeoncross wrote:
| I appreciate the detailed answer, thanks. However, It feels
| like $a->foo vs $a->foo() is a personal preference that
| hides the fact you're doing work behind the scenes.
|
| Then again, I'm not a fan of code that does magical things
| that aren't apparent. Makes it a lot harder to 1) reason
| about and 2) solve performance issues. I also don't want
| the overhead of function lookups for every property access.
| acabal wrote:
| Getters aren't for everything. But for a basic CRUD case
| like above, they're a nice way of having a clean OOP
| contract by demarcating a clear difference between
| properties, which are pieces data attached to the object
| that the caller can read and write, and methods, which
| are the caller can change the object's or app's state, or
| perform actions with possible side-effects.
|
| Very often for a typical CRUD app, I _as the caller_ don
| 't really care how we got the `LastForumsPost`. It's just
| an object mapping that comes from some data source like
| the database. And if I do care, I could get it outside of
| the object, and set it myself.
| dragontamer wrote:
| The more I program the more I realize that we are all blind
| men feeling out an elephant.
|
| It sounds like you got the gist but somehow you are in an
| area of programming where getter/setters aren't useful.
|
| That's fine and okay. Part of growing up as a programmer is
| realizing your niche.
|
| Most of the advice out there is deep, not broad. It's deeply
| connected with our niche and not necessarily broadly
| applicable.
| smt88 wrote:
| This was weirdly condescending and content-free.
|
| I've been programming for 30 years, and getters/setters are
| both pointless and anti-productive.
|
| They hide (potentially a lot of) code from people reading
| the program, which leads to a lot of "wtf" moments later.
|
| Magic in general is bad, and it's the kind of "look how
| concise and clever I am" thinking that leads to
| unmaintainable software.
|
| If setting a property isn't straightforward, make it
| private/protected and add explicit getter/setter methods.
| It's more work today and much less work later on.
| hparadiz wrote:
| Every php ORM disagrees. Nothing about it is magic
| smt88 wrote:
| PHP ORMs and ORMs in general are notoriously hard to
| maintain. I've written hundreds of thousands of lines of
| PHP, I'm speaking from experience.
| keybored wrote:
| It sounds like you got the gist of the critique of
| getters/setters but just haven't been exposed to the
| alternatives.
|
| That's fine and okay.
| hparadiz wrote:
| They are used in ORMs to do property value conversions from
| PHP primitives to values a data store might actually want.
|
| I wrote about it here https://technex.us/2023/07/php-
| attributes-are-so-awesome-i-j...
| whalesalad wrote:
| Getters are great for manipulating data on the way out. For
| instance, inside the class you might store a raw
| representation of the data like a json string, but when
| reading an attribute you will decode that json string into a
| datastructure and pluck a certain item. I use dynamic getters
| often to wrap a raw value with some kind of fallback: do this
| if no data is present, do this if the data is present but is
| ancient (ie a seamless upgrade of a v1 internal datastructure
| to a v2 output), etc. For setters, I try not to have implicit
| side effects but in certain cases where it makes sense, it is
| nice to be able to centralize that logic: "if this value
| changes, ensure x and y occur" which you get "for free
| throughout your codebase when you use a setter, versus having
| to go thru the entire codebase and sprinkle the do_x() and
| do_y() calls (which then becomes additional footprint to
| maintain and worry about)
| foolfoolz wrote:
| this was the one feature i read in here thinking "why would
| anyone want this?"
|
| seemed like a way to backport poor librar/framework choices to
| have IDE support but not for new code
| munk-a wrote:
| I've written some auto-getter and setter spawners and with
| reflection it's pretty do-able to implement proper type
| checking as long as the type you want to check for matches the
| type declared on the property. PHP meta-coding is actually
| quite advanced and pretty accessible compared to what I've done
| in other languages.
| PaulHoule wrote:
| That "public private(set)" boggles my mind. Why not "readonly
| public"?
| wvenable wrote:
| 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.
| radicalriddler wrote:
| 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 wrote:
| Standards compliance for HTML is huge. Hopefully everyone
| switches to it ASAP.
| dmsnell wrote:
| 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?
| bornfreddy wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| LeftHandPath wrote:
| 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.
| hasnain99 wrote:
| I don't Use Php but I think learning Php its better than to learn
| Typscript
| that_guy_iain wrote:
| The breaking changes section doesn't even mention they changed
| error handling in methods that haven't been change for 20 years.
___________________________________________________________________
(page generated 2024-11-21 23:00 UTC)