PHP 8.4 Released With Property Hooks, Lazy Objects & Other New Features

[uid313]

I agree with you about needing a more ergonomic HTTP client. Guzzle and the like are fine and all, but it's exactly the sort of niche the standard library ought to fill—especially since we're already most of the way there with stream wrappers. It just needs to have a proper API.

As for UUIDs, as someone who wrote one such third-party library, it would be nice, but I haven't had it come up much.

I'm baffled about your complaints over JSON, though. You'd need a lot of plumbing to map JSON to arbitrary classes, wouldn't you? Does anything do that?

in .NET you use the JsonSerializer class in the System.Text.Json namespace and you use generics to specify the class and pass it a string as argument then it deserialize and return a instance of that class you specified where each key in the JSON is mapped to a property in the class. It is very nice and you can give the function an option class so you can configure if you want to serialize from camelCase or PascalCase or kebab-case, or under_score. If you want you can put attributes on the properties if the name of your property in your class is different from the key in the JSON. You can also do polymorphic JSON so you can have many different classes each with different properties and which class it uses depends on the type discriminator which is a key which defines what type of object it is, so it is great for JSON-LD too.

I am sure Java have powerful JSON too. The serde-json library in Rust was alright too. In my experience JSON have been the poorest in PHP and Python.

[J.King]

A very good update with lots of new great improvements. Personally I think the new asymmetric visibility thing is confusing.

I think that the syntax for property hooks is a bit verbose since you have to repeat the data type and the variable name, this is much cleaner in C#.

I would like to see PHP support for expression-bodied functions like they have in C# so that you can write a function on one line with => arrow and skip the return keyword.

I think PHP have some problems:

• JSON support is very poor, you can only serialize to stdClass or an associated array, not to your own classes so you don't have type safety, and you cant override property names if you want to serialize a kebab-case JSON into a camelCase property.
• There is no support for UUID (I know there are third-party libraries available, but I think it should be in the standard library).
• HTTP support is very poor, you have to use the very awkward libcurl, I would like to see a modern HTTP request support in the standard library, like the Fetch API in JavaScript, the HttpClient class in .NET, or the requests/httpx library in Python.

I agree with you about needing a more ergonomic HTTP client. Guzzle and the like are fine and all, but it's exactly the sort of niche the standard library ought to fill—especially since we're already most of the way there with stream wrappers. It just needs to have a proper API.

As for UUIDs, as someone who wrote one such third-party library, it would be nice, but I haven't had it come up much.

I'm baffled about your complaints over JSON, though. You'd need a lot of plumbing to map JSON to arbitrary classes, wouldn't you? Does anything do that?

[uid313]

Sounds like you want Laravel Route Model Binding + Laravel Form Requests (maybe even API Resources). Pretty simple stuff, and as always there a packages to make it even simpler.

Yeah, probably Laravel can do this, and probably Laravel is a great framework, but I really wish PHP had great support for JSON and a great HTTP client out-of-the-box.

[murraytony]

Yes, exactly, I would have an RESTful endpoint so I know how to deserialize based on the name of the endpoint which is in the URI, so for example I would have the HTTP endpoint /api/pets/ which accepts GET and POST requests, and I would have /api/pets/{id} which accepts GET, PUT and DELETE requests so when a client does a POST request against the pet endpoint I know that I should attempt to deserialize the request body into a Pet object which would be an instance of the Pet class. If the deserialization would fail I would return the HTTP status code 400 Bad Request.

Sounds like you want Laravel Route Model Binding + Laravel Form Requests (maybe even API Resources). Pretty simple stuff, and as always there a packages to make it even simpler.

[Jonjolt]

Ok that's nice. Previously 'killall java' killed all Java apps? I've noticed that IDEA doesn't use that executable name anymore but I thought they had customized their JDK somehow.

They probably use a launcher, jpackage can make a custom launcher but it doesn't expose a lot of configuration options and is more desktop oriented, basically when you see a JVM app without a console under Windows they are using a custom launcher. Literally it is native code that starts up the JVM

Sources here for jpackage https://github.com/openjdk/jdk/tree/...c/jdk.jpackage

[caligula]

I'm using jlink in production, lol one of the best features is just renaming the executable instead of trying to track down which process is which.

Ok that's nice. Previously 'killall java' killed all Java apps? I've noticed that IDEA doesn't use that executable name anymore but I thought they had customized their JDK somehow.

[uid313]

You're probably aware that such deserialization can be a security risk? Java serialization libraries provide fine-grained control over what can be deserialized.

No, I don't think so, not JSON deserialization. Sure with marshaling (such as Pickle in Python) where you do some binary deserialization which deserializes methods and everything but not JSON which have no methods, only properties which can be number, string, array, object and boolean. Maybe if you deserialize properties with __ double underscores in their name as that is dunder in Python and magic methods in PHP but a JSON deserializer should take to properly deserialize a string.

OK but when objects are sent back to your PHP server, doesn't the URI structure tell your app what class of object it's dealing with already? (That is just how I see it being done normally.) Sorry if I'm being a PITA with the questions but I'm trying to grok what you'd like PHP to do, that other languages do better. Like, the Javascript end can't know implicitly the class from just the JSON either, unless both ends have a shared protocol to determine that based on the content's data or message metadata.

Yes, exactly, I would have an RESTful endpoint so I know how to deserialize based on the name of the endpoint which is in the URI, so for example I would have the HTTP endpoint /api/pets/ which accepts GET and POST requests, and I would have /api/pets/{id} which accepts GET, PUT and DELETE requests so when a client does a POST request against the pet endpoint I know that I should attempt to deserialize the request body into a Pet object which would be an instance of the Pet class. If the deserialization would fail I would return the HTTP status code 400 Bad Request.

[Havin_it]

I want PHP to expose a RESTful Web API endpoint that serves JSON to be consumed by other clients and web applications like SPA JavaScript applications like React, Vue and Svelte.

OK but when objects are sent back to your PHP server, doesn't the URI structure tell your app what class of object it's dealing with already? (That is just how I see it being done normally.) Sorry if I'm being a PITA with the questions but I'm trying to grok what you'd like PHP to do, that other languages do better. Like, the Javascript end can't know implicitly the class from just the JSON either, unless both ends have a shared protocol to determine that based on the content's data or message metadata.

[caligula]

I want PHP to expose a RESTful Web API endpoint that serves JSON to be consumed by other clients and web applications like SPA JavaScript applications like React, Vue and Svelte.

You're probably aware that such deserialization can be a security risk? Java serialization libraries provide fine-grained control over what can be deserialized.

[Jonjolt]

Funny thing is the next Java version will cut down even more bloat. Their jlink will leave out more unused code and the runtime representation of objects slims down a lot.

Here's a list of new features for Java 24:
https://openjdk.org/projects/jdk/24/

I'm using jlink in production, lol one of the best features is just renaming the executable instead of trying to track down which process is which.