13 ms·
Whats New in PHP 8.2
- hu3 4y agofunction alwaysFalse(): false { return false; } This function return is... interesting.
- alex-zierhut 4y agoAS far as I know, this is because it was and still is common practice to return a result from a function, but return false if something didn't work. Having this type helps return type declaration like: false|ResultObject In my opinion, using Exceptions or nullable types is a better practice in those cases, but I am not against having more options.
- nicoburns 4y agoYeah it makes a lot of sense just to be able to type existing functions. Seems weir d not to allow true though. I feel like both should be added for completeness.
- matsemann 4y agoKinda make sense, though, as what would that "true" really mean? That the function succeeded? But then the result should be the output.
- cestith 4y agoI don't mind a unit type for failure. I just don't think it should be called "false". Maybe make true and false Boolean and have a unit type for failures called "fail" or "failure".
- djbusby 4y agoPEAR_Error
- simion314 4y agoI think for new code Exceptions are the preferred solution in case your code errors out , much more clear to return just one type of data. So this seems to be just a solution for improving type declaration for older code that that use the pattern to return false in case of error instead of an exception with a much more clear information on what went wrong.
- sfteus 4y agoRight, in the context of PHP it makes sense, as bool would imply you might need to handle a truthy value when in reality the return type of several built-in functions is result|false. Nullable types generally work well, unless you're you have a function that may return nothing, or an error. IE findUser(string $name): ?User wouldn't be able to differentiate between a database error or just not finding a user with that name. Exceptions would work fine here (specifically due to a DB error), but seem a little superfluous for smaller functions. Personally, I've grown to love the tuple return types of Go/Rust, and I'd love to see first-class support for that within PHP. You can emulate it by returning an array and unpacking it / using list(), but it adds a decent amount of boilerplate and you lose aspects of type covariance in always returning an array.
- muglug 4y agoThe site doesn't make it clear, but this isn't a full list, since PHP 8.2 will be accepting RFCs until mid-July (see https://wiki.php.net/todo/php82 https://wiki.php.net/todo/php82 for the release timeline). Even though it's incomplete, this page helps to generate excitement about PHP generally, which is a good thing — the PHP community sometimes struggles with its reputation as a dying language.
- deleted 4y ago[deleted]
- whenlambo 4y agoDying? “PHP is the most used server-side programming language globally” https://kinsta.com/php-market-share/ https://kinsta.com/php-market-share/
- dabernathy89 4y agoThey said "reputation", not that PHP was _actually_ dying
- antifa 4y agoMostly people who've never written a line of php in their life assuming the same about everyone else.
- kstrauser 4y agoI think those can both be true. For instance, Google Trends[0] shows interest in it falling significantly with time. However, Wordpress is written in it, so a lot of people are still running PHP on their servers. I wonder if PHP:Wordpress is becoming like Ruby:Rails, where there’s no reason you can’t use the language for other things, but in practice it’s mostly used for one specific purpose? [0] https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F060kv,%2Fm%2F05z1_,%2Fm%2F05zrn https://trends.google.com/trends/explore?date=all&geo=US&q=%...
- 4y ago
- Ciantic 4y ago> Deprecate dynamic properties That's pretty big one. Lot of JSON can be deserialized to basically bunch of objects with dynamic properties, since it's parameter in deserialization. For example `json_decode("...", false)` where second parameter (false) explicitly says it should return object. After that it's typical to set values such as `$post->name = 'Name';`, which would now give warning and in PHP 9 an error. Maybe we shouldn't characterize PHP as dynamic language after the change?
- mhitza 4y agoFrom the RFC https://wiki.php.net/rfc/deprecate_dynamic_properties https://wiki.php.net/rfc/deprecate_dynamic_properties > stdClass and __get/__set are not affected by this change. Your json example, or object cast of an array, or directly defining properties on a stdClass will not cause a deprecation.
- coolgoose 4y agoClasses marked with #[AllowDynamicProperties] as well as their children can continue using dynamic properties without deprecation or removal. The only bundled class marked as #[AllowDynamicProperties] is stdClass. Aka stdClass based obj's are still fine to have dynamic properties. So mostly sure it's still going to work.
- wackget 4y agoYeah this seems like a bad one to me.
- tored 4y agoIt is only for classes not for objects (stdClass). You can mark a class with the attribute #[AllowDynamicProperties] to allow dynamic properties. You can also still implement the __get/__set methods on the class to have dynamic properties. What this RFC does is to remove not declared dynamic properties. https://wiki.php.net/rfc/deprecate_dynamic_properties https://wiki.php.net/rfc/deprecate_dynamic_properties
- thinkindie 4y agojson_decode('...', false) will deserialize into a stdClass - which I guess implements magic methods __set() and __get. I've never checked this but I guess that would do the trick has mentioned in the article itself.
- alex-zierhut 4y agoThe last few years have brought insane progress to the PHP language. I absolutely love the direction. Personally, the next feature I'd like to see the most is a great implementation of Tasks / Asynchronously, something the language always lacked, possibly because it is nearly exclusively used with web servers. I mostly get around that by extensively using queues, software like RabbitMQ, and spawning micro services. I would like to see it move towards more general purpose usability.
- blowski 4y agoLike Fibers? https://www.php.net/manual/en/language.fibers.php https://www.php.net/manual/en/language.fibers.php
- kijin 4y agoFibers don't run concurrently with the main thread. They're like preemptive multitasking, not simultaneous multitasking. For example, if you have a long-running database query, disk I/O, or some other blocking function, you can't simply send it to the background and do something else while waiting for the result. Network requests are better, but only because the underlying functions support a rudimentary form of async calling.
- tored 4y agoSomeone has apparently implemented async library with fibers and stream wrappers. https://www.reddit.com/r/PHP/comments/u80gyg/true_coroutines_like_go/ https://www.reddit.com/r/PHP/comments/u80gyg/true_coroutines...
- exikyut 4y agoPHP seriously needs an event loop. The Node model, where things that call into libuv to wait on servers and such prevent the script from exiting, is simple enough to implement and while mildly unintuitive to newcomers is still accessible thanks to Node's popularity.
- 4y ago
- tored 4y agoPHP 8.2 will probably not add many new features more of cleaning up the language (still important ofc), similar to PHP 7.2 or PHP 7.3. PHP 7.4 did however add a lot of interesting features like FFI, JIT, preloading, typed properties and arrow functions. Thus if PHP 8 development will by any way similar how PHP 7 was developed you need to hang in there for at least one more release but probably two more releases or wait for PHP 9.
- kijin 4y agoMakes sense. It takes time for new features to get traction and iron out any missing parts that the original RFC didn't think of. Lots of software projects alternate between new-feature releases and cleanup/bugfix/housekeeping releases. Users also like to have a period of stability before they need to change things up again.
- bufferoverflow 4y ago> and false as standalone types That's just wrong. Boolean is the type. False is just one possibile value of that type.
- blowski 4y agoIt's for backwards compatibility with functions that return either the expected value (maybe an array or a string) or false (never true). So you can use it in a union like `foo(): string|false {}`. In that sense, it's not a boolean because it will only ever be a string or false.
- tyingq 4y agoThat makes sense, though you would want a linter or something to check that callers are doing "=== false" and not "== false", since falsy (but not false) values would match the latter.
- Dragony 4y agoSadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In those cases the `false` type is more accurate than boolean. That's the reason for the distinction.
- cestith 4y ago
- bovermyer 4y agoSo essentially, PHP 9.0 is a different language, and not compatible with the vast majority of PHP applications out in the wild. This isn't necessarily a bad thing, but it does mean that a lot of applications are going to be stuck on old versions. For my part... I think this will make me fully abandon PHP and just rewrite old apps in other languages, like Go and Rust.
- zozbot234 4y agoIs there an easy way of doing HTML templating with Go/Rust, as you would in PHP?
- bovermyer 4y agoNot as easily as in PHP, but yes. https://pkg.go.dev/html/template https://pkg.go.dev/html/template (for Go)
- radlad 4y agoIMO the template package in Go is kind of awful. The contextual escaping is very cool (although a little frightening given the complexity of it), but the ergonomics of parsing, nesting, and executing templates is very confusing IMO.
- 0des 4y ago> the ergonomics of parsing, nesting, and executing templates is very confusing IMO Can you elaborate on this?
- smt88 4y agoRust has lots of template libraries. HTML templating is a solved problem that PHP doesn't uniquely do well anymore.
- steve_adams_86 4y agoI guess that depends on what you mean by “as you would in PHP”. I assume everyone uses something like Twig these days, so in that case, absolutely. You even get compile time checking from Rust libraries like askama: https://github.com/djc/askama https://github.com/djc/askama
- alberth 4y agoPHP has really become quite great to work with. I wish there was a fork of PHP that cleaned up all the things that would break backward compatibly (e.g. have consistently method naming, clean up type casting for methods that do that which can today lead to weird bugs, etc). Essentially, haven't an entire "clean" language to work with.
- caditinpiscinam 4y agohttps://hacklang.org/ https://hacklang.org/
- alberth 4y agoI was under the impression that even though Hack no longer is backward compatible with PHP - that in practice, it's still largely the same (not much has changed). Or am I mistaken?
- tored 4y agoLots of changes. Like built in async, generics, shapes (typed associative arrays) and I learned the other day here on HN that XML templating is built into the language, somewhat similar to JSX.
- slimginz 4y agoJSX in React was actually based on XHP (Hack's XML template framework) since both were developed at Facebook
- francislavoie 4y agoA fork would completely fracture the community. No thanks.
- dcgudeman 4y agoThere already is a fork, https://hacklang.org/ https://hacklang.org/. It didn’t fracture the community, people just don’t use hack.
- allendoerfer 4y agoThe most annoying thing you encouter daily in PHP is the needle/haystack problem. There is no consistency with parameters of the standard library. It could be fixed in two ways: a) Make everything an object, where methods can be called on: $arr = []; $arr->key_exists('key'); b) Create a new class-based standard library, where you call those functions statically and needle/haystack are always in the same place: Arr::key_exists($arr, 'key'); Either way, you can deprecated all the array_..., str_..., etc. functions and end the guessing game. Other than that PHP is turning out great.
- conradfr 4y agoThis is so funny to me how it's constantly brought up here but has never been an inconvenience to me, and I started with PHP3 in 1998. Even before auto-completion I guess I would just read the docs. To each his own I guess.
- Reubensson 4y agoI am sure that if you use a language/library for long enough, its bad design descisions aren't a huge problem to you. Reading the docs of course helps, but it is still inconvenience and waste of time to check inconsistent parameter order and function naming from docs. I don't understand why people are so keen on defending these things.
- purerandomness 4y agoIt really is irrelevant nowadays, with a) all IDEs showing you the required parameters as you type, and b) with named parameters.
- francislavoie 4y agoUserland frameworks/libs provide those kinds of helper classes already. And IDEs completely solve the problem of knowing parameter orders by hinting them as you type the functions. This really isn't that big of a deal.
- Helitioo 4y agoFunny to see PHP staying weird. Introducing false and null loving it :D
- Epskampie 4y agoFor an always up-to-date overview check out PHP RFC Watch https://php-rfc-watch.beberlei.de/ https://php-rfc-watch.beberlei.de/ Not a dig against sticher.io, love their to the point descriptions.
- thibran 4y agoThe feature I missed the most when writing PHP was something like a pipeline operator to easily chain functions. https://stackoverflow.com/a/55143445 https://stackoverflow.com/a/55143445
- tyingq 4y agoIt was considered, but declined: https://wiki.php.net/rfc/pipe-operator-v2 https://wiki.php.net/rfc/pipe-operator-v2 Laravel has pipelines, but it's not generically useful for existing functions. https://dev.to/abrardev99/pipeline-pattern-in-laravel-278p https://dev.to/abrardev99/pipeline-pattern-in-laravel-278p
- AdrianB1 4y agoIs there any programming language that changed so much as people that know the initial versions will not be able to understand the latest one? This is my impression about PHP and I cannot remember a single other such case. My memories go back to the 80's (Basic, Pascal, Cobol, SQL), I am not familiar with the current state of C, but my feeling is that the latest PHP and the original PHP share little more than the name.
- nobleach 4y agoIt's entirely possible. I wrote my last real PHP in 2014. Even then I was maintaining a very old app. I did write a quick API in Laravel back in 2017 just to see what all the fuss was about. And even then. PHP felt a LOT different. I keep an eye on the language and I'll admit, it's VERY far from what I originally used. That's a good thing.
- astrange 4y agoPerl changes a lot; I'd say C++ changes a lot, but they just constantly add stuff without removing much or caring how easy it is to make dangerous mistakes in it.
- ipaddr 4y agoNot a fan of Deprecate dynamic properties. This is one change/direction that may make me reconsider php in the future.
- lkrubner 4y ago"PHP used to be a very dynamic language, but has been moving away from that mindset for a while now." For gods sake, if I want a stricter language, then I will use a stricter language. I've used Java for many things, I've used Scala for one large project, and PHP will never be able to compete as a strict language. I don't understand why language maintainers would decide "People love this language, but let's try to transform it into a different language." I've the same criticism of Python, I think it should have continued with the design goals and philosophy of 2.x, I think the attempt to become more object oriented was a mistake, I think 3.x was a mistake. There was a philosophical cleanness in 2.x that is missing in 3.x. Some language communities suffer a crisis of confidence and then they try to become something else, but this is always a mistake. As we saw with the transition from Python 2.x to 3.x, it takes 10 years to transition a language community, and meanwhile a developer can simply learn a new language in 6 to 12 months. That is to say, the developers can adjust much more quickly than the language, so each language should try to stay true to its original vision. Borrowing some good ideas from other communities is fine, so long as a clean implementation can be envisioned. But taking a language that was famous and adored for its sloppiness and dynamicness and then trying to make it strict? This is a bad idea.
- adlpz 4y agoI agree, but at the same time I've lived the PHP transformation as a professional developer and I think I know the reasoning. Maintainers and supporters of a language are usually people that are professionally very invested in the language. And therefore it's natural for them to steer the language towards fixing their pains first and foremost. And anyone who's been invested into a language for a long time, with lots of old code to improve and maintain, an enormous muscle memory for all things related to the language, thousands of snippets, patterns and libraries in your tool belt, knows that changing languages is not trivial. For someone directly involved into the language governance, it's actually easier to change the language. Even if that goes against the languages original spirit.
- mike503 4y agoHonestly, I'm a little sad about PHP's direction. What I enjoyed most about it was it's simplicity. It seems like at this point everyone is trying to add $everything_i_like_about_java and $everything_i_like_about_javascript etc. It's almost like this is "phpng" now. I've always dreamt of a purely procedural PHP fork, removing all the overhead for object management. Keep things as functions, arrays, and I'm even cool with type juggling. Fix the needle/haystack stuff, but basically a "scripting" layer relatively close to being on top of C, in a way. I can do a ton of amazing things without the need of OOP/objects/autoloaders and basically anything else introduced after PHP 5.x. :) - "damn kids get off my lawn!"
- deleted 4y ago[deleted]