On Mon, Nov 15, 2021, at 10:52 AM, Rowan Tommins wrote:
> On 15/11/2021 16:23, Andreas Heigl wrote:
>> One thing, that can verify the correct working of properties, whether 
>> that is dynamic or static ones, is testing.
>
>
> Can it? I can't actually see how that would work, without also having a 
> way to detect when dynamic properties were accessed, which brings us 
> full circle. Also:
>
>
>> So the mistakes-part would be easy to handle. 
>
> If you are working with a million lines of code going back 20 years, 
> "write tests for everything" is not "easy to handle"; it's a long-term 
> ambition which you chip away at when priorities allow.
>
> "Logging all deprecations and warnings on a production workload", 
> however, *is* easy to handle. Diagnostic messages in logs are the *only* 
> way this behaviour will be spotted in old code.
>
>
>> What I am still missing is the differentiation between "everything is 
>> strict and you have to explicitly opt-in to make it dynamic" and an 
>> "everything is dynamic and you can use a marker to mark this 
>> explicitly an intended behaviour". That would allow users to mark a 
>> class explicitly to use dynamic features even though it would make no 
>> difference code-wise.
>
>
> I'm not sure what you mean by that. Do you mean, create the attribute, 
> but don't actually do anything with it? Would the plan be to deprecate 
> later? Never remove at all?

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.
9.0: Change the deprecation to an error, if the attribute is set false (which 
by now is the default) and dynamic properties are used.
Sometime in the future: Setting the attribute to true triggers a deprecation.
Sometime in the future: Remove dynamic properties entirely, and the attribute 
along with it.  People can use __get/__set if they really need.

This still gets us to the same place in the end, but introduces another stage 
along the way to make the transition more gradual.  We can debate which version 
the default should flip in, I don't much mind.  That could even wait for 9 if 
we want to be really really gradual about it.

Meanwhile, IDEs and code templates can start including the attribute set to 
false by default on any new classes that get written, just like they have done 
for years with strict types.

Nikita, would that be feasible?  Matthew, Derick, would that be satisfactory?

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to