Hey Rowan, hey all On 15.11.21 17:52, 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:
When you are testing whether writing 'X' to a property and then reading from that property gives that 'X' back, then everything should be good.
You either typed the name of the property correctly or you have a typo in the setter and getter (or however you set and got the value). Nevertheless you should be able to figure out whether you accidentally misstyped a property name somewhere as that should break the test (unless you misstyped the name twice). ANd whether you are doing the assignement to a static property or to a dynamic one should be irrelevant, the reading and the writing process are the same.
Yes: That rips off a completely different topic: Testing "getters" and "setters".
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.
The intention is not to write tests for existing code. As the intention is exactly to be able to leave existing code as it is. Otherwise the approach to "add the Attribute and be done" would be much easier.
The intention is much more to make sure that *new* code does not write accidentally to the wrong property. Which is what this RFC is all about. Make sure that dynamic properties are not accidentally used.
"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.
That is absolutely correct. The main question is: "Do we *need* to spot this behaviour in old code"? Not "Do we *want* to spot this behaviour in old code".
As currently there is no direct intention to remove the feature for good, why should we force it? And espechialy why do we need to force those maintinaing existing code to adapt their 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?
For now the possibility could be to keep everything *as is*. Plus add an attribute to make absolutely explicit that we want to use this feature. The next step could then be to create a setting that will notify about dynamic assignments in classes that are not marked by the attribute. I'm not talking about a deprecation note here. More something like a notice (not a warning as that is too severe!). That way the behaviour can come up in log files. Perhaps a new Level of notice like a "bad_coding_practice". Or we use different "lanes" of reporting. One for notices, errors, warnings et al and one for deprecations and such asignment-oddities. When that has been done (should so far all be BC) and code-maintainers have had enough time to modify their codebase (definition of "enough time" is here clearly the main topic and needs discussion with maintainers!) then we can talk about possibly phasing out the feature.
My 0.02€
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
