On Wed, Apr 24, 2024 at 7:18 PM Jorg Sowa <jorg.s...@gmail.com> wrote:
> I like the proposition and I like the idea of $since parameter, however,
> this option is too ambiguous about what should store. Should it store the
> PHP version, package version, or the date?
>
> What about setting this parameter vaguely as the boolean we can pass?
>
> #[Attribute(Attribute::TARGET_METHOD | Attribute::TARGET_FUNCTION)]
> class Deprecated
> {
> public function __construct(
> public readonly ?string $note = null,
> public readonly ?bool $since = null
> ) {
> }
> }
>
> #[Deprecated(since: $packageVersion > 5.5)]
> #[Deprecated(since: PHP_VERSION_ID > 80100)]
> #[Deprecated(since: date("Y-m-d") > "2024-01-21")]
>
These are not valid uses of attributes, the expressions for since parameter
are illegal in the language.
PHP Fatal error: Constant expression contains invalid operations in
/private/tmp/dep.php on line 6
And this proposal would only make the condition human readable, the machine
would see $since as either true or false, and that is not really something
that tools will find valuable enough.
But I agree on $since being less useful, users could put a date, a string,
or anyhing in there.
The way I see it vendors should add their own attributes, example:
#[\Deprecated, Since(package: "symfony/http-request", version: "7.0.2")]
or for PHPStorms replacement functinoality (potentially usable by Rector):
#[]Deprecated, Replacement('%class%->setPublic(!%parameter0%)')]
This is
a.) composable, which increases the potential use-cases for different
vendor and communities and doesn't restrict them to what core "designed in
the ivory tower once".
b.) allows vendors to have very strict validation on their attributes
arguments. I.e. Symfony could enforce package to be a valid composer
package string and version to follow composers version parser. This is
something we cannot enforce in the engine.
>
> Kind regards,
> Jorg
>
