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 >