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
