PHP 8.2 compability

[salerat]

Feature Request

Q	A
New Feature	yes

Summary

Due installing by composer i get next error while using PHP 8.2 RC:
- laminas/laminas-code 4.7.x-dev requires php >=7.4, <8.2 -> your php version (8.2.0beta1) does not satisfy that requirement.
Looks like this is last package which includes in Symfony 6.2 which not supports PHP 8.2

[Ocramius]

Correct: this package does not yet support PHP 8.2.

PHP 8.2 compatibility will be rolled out once all features from PHP 8.2 are implemented/tested:

• https://wiki.php.net/rfc/dnf_types
• https://wiki.php.net/rfc/true-type
• https://wiki.php.net/rfc/readonly_classes
• https://wiki.php.net/rfc/null-false-standalone-types

[agustingomes]

Now that the PHP 8.2 has reached Release Candidate phase, I think is a good moment to add the new features, and in the process, drop support for PHP 7.4.

I'll personally try to invest some hours in the upcoming weeks to get some of the new 8.2 features in.

[guradia]

I have a codebase with Symfony 6.1.x at hand, that does work fine under PHP 8.2.
But doing anything with composer gets blocked by this constraint.

So i think the constraint is kind of erroneously applied?

Meaning:
Coming from the view of features this library understands, sure ... it does not support PHP 8.2.
But the constraints applied to a library should be about the compatibility of the library itself.
So to speak: PHP 8.2 understands the library and can run it's things ... the other way around should not be relevant and only be something the documentation of the library states, but does not dictate it can't be installed under higher PHP-Versions.

Addendum:
My understanding of this library is, that it's compatibility is meant in way of what it can statically analyse. And this is separate from it's one execution context. It can probably analyse 8.1 code, even when executed on 8.0?

[Ocramius]

@guradia just cross-referencing: laminas/laminas-diactoros#117 (comment)

As for PHP 8.2 support, hoping to throw some time at this soon: haven't found any yet, and I've already upgraded a few hundred other packages so far. Patience.

[guradia]

@Ocramius ah, yes. This reasoning about SemVer is totally sound. And to be square with myself: Me going early adopter is obviously calling for trouble and is my problem alone.

Having concluded that, i just ran the test suite for the library under PHP 8.2 and did the composer run with "--ignore-platform-req=php+" for the Symfony codebase. Since i am now being confident with that.

May such a test run be of any contribution value?

[Ocramius]

@guradia practically, there's a bunch of stuff in the 4.8.0 milestone that needs to happen before 8.2.0 is considered viable.

In this component's case, "it runs" is not sufficient to declare PHP 8.2 compatibility.

[fezfez]

Correct: this package does not yet support PHP 8.2.

PHP 8.2 compatibility will be rolled out once all features from PHP 8.2 are implemented/tested:

* https://wiki.php.net/rfc/dnf_types

* https://wiki.php.net/rfc/true-type

* https://wiki.php.net/rfc/readonly_classes

* https://wiki.php.net/rfc/null-false-standalone-types

based on this comment, here is the path to release PHP 8.2 compat

Feature	Merge request	done?
https://wiki.php.net/rfc/dnf_types		No
https://wiki.php.net/rfc/readonly_classes	#147	Yes
https://wiki.php.net/rfc/true-type	#149	Yes
https://wiki.php.net/rfc/null-false-standalone-types	#149	Yes

Is there someone working on https://wiki.php.net/rfc/dnf_types ?

[fezfez]

@Ocramius i think you are working on https://wiki.php.net/rfc/dnf_types ?
( https://twitter.com/Ocramius/status/1593678065103667208/photo/1 )

[Ocramius]

Ya, didn't commit anything yet though

[Ocramius]

@fezfez if you want to do DNF types, the TypeGenerator is mostly @internal, so you can rewrite it completely, if you want :D

[fezfez]

@fezfez if you want to do DNF types, the TypeGenerator is mostly @internal, so you can rewrite it completely, if you want :D

haha, okay i will probably in the week

[arokettu]

@guradia practically, there's a bunch of stuff in the 4.8.0 milestone that needs to happen before 8.2.0 is considered viable.

In this component's case, "it runs" is not sufficient to declare PHP 8.2 compatibility.

laminas-code technically has 2 PHP compatibility targets: for a host platform and for a target platform. Currently they are treated as unified but I don't see any good reason for them to be strictly aligned. My current generation target is 5.6 for example and I suspect it to be the most common use case, for people wanting to run their old generation code for old targets on the updated platform

[IonBazan]

Currently they are treated as unified but I don't see any good reason for them to be strictly aligned.

In fact, Readme states that this tool could potentially be used to generate code for other targets:

While the current implementation is limited to generating PHP code, you can easily extend the base class in order to provide code generation for other tasks: JavaScript, configuration files, apache vhosts, etc.

[Ocramius]

The problem with them being aligned is that this code extends ext-reflection too, so it must stick to it to some degree, or else madness (in maintenance) ensues.

Anyway, I think DNF types are the last bit missing.

In fact: if this component encouters a DNF type at runtime, it currently crashes hard.

[arokettu]

@Ocramius thanks for the explanation

[faizan-shk]

@Ocramius any ETA when 8.2 Compatibility for laminas-code will be added. Almost all other laminas packages have added support for php 8.2!

[Ocramius]

@faizan-shk the ETA is "whenever @Ocramius has a free weekend to throw a good chunk of time at this".

[Ocramius]

It is done!

[driehle]

Thank you, @Ocramius, for your great work! 👏