Re: Re: [RFC] Deprecate dynamic properties

On Tue, Nov 16, 2021, at 4:10 PM, Sara Golemon wrote: > On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield <larry@garfieldtech.com> > wrote: > >> A possible idea to help make this transition (which I do support) more >> gradual: >> >> Instead of an "allow" attribute, introduce a boolean flag attribute. >> >> #[DynamicProperties(true)] >> class Beep {} >> >> The attribute marks whether dynamic properties are enabled or disabled via >> boolean. If disabled, then they're an error if used. >> >> 8.2: Introduce the attribute, with a default of TRUE. Exactly zero code >> breaks, but people can start adding the attribute now. That means people >> who want to lock-out dynamic properties can do so starting now, and those >> cases that do need them (or can't easily get away from them) can be flagged >> far in advance. >> 8.something: Change the default to FALSE. Using dynamic properties when >> false throws a deprecation, not an error. People have had some number of >> years to add the attribute either direction if desired. >> > > This is exactly what Nikita is proposing, except that instead of the > attribute being introduced in PHP 8.2, he's proposing to introduce it > EARLIER. Roughly PHP 2 sort of timeframe. > > This is because attributes are forward compatible by design and developers > can already start adding #[AllowDynamicProperties] to their code NOW. Even > their code that was written to run cleanly on PHP 5.6 because users are > terrible at upgrading their servers despite a 2x performance increase. > </rant> > > The point is, we don't need 8.2 to be a soft-launch before deprecation > because precisely nobody is prevented from adding this attribute > preemptively. > > -Sara It's not *quite* the same, although your point about preemptive attributes is valid. 1. If we adopt the RFC right now as-is, the market has ~12 months to add the attribute. If we instead have a default-true flag that changes to default false in the future, it means at minimum 24 months in which to add the attribute to opt-in to dynamic properties. 2. The RFC as-is has no way for developers to opt-in to actively rejecting dynamic properties. They'll get a deprecation, but... we're shouting from the rooftops that deprecations shouldn't be a big red warning, so if you want a big red warning you can't get that until PHP 9. With the flag attribute, developers could opt into "please slap me across the face if I use dynamic properties by accident" in ~12 months when 8.2 ships, rather than waiting 36-48 months until the likely PHP 9 release. So it gives the nitpickers what they want sooner, and gives the old-codies more time to get their ducks in a row. --Larry Garfield