On Thu, Nov 16, 2023 at 5:41 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> Hi all, > > I have finally written up an RFC I have been considering for some time: > Harmonise "untyped" and "typed" properties > > RFC URL: https://wiki.php.net/rfc/mixed_vs_untyped_properties > > > Currently, changing a property declaration from "private $foo" to > "private mixed $foo" changes its behaviour in significant ways, even > though no actual type checks are added. This RFC seeks to remove those > differences, by extending the "uninitialized" state currently reserved > for typed properties to cover all declared properties: > > * Properties without an initial value will be "uninitialized", not "null" > * Calling "unset" on a declared property will make it "uninitialized", > rather than the current complex behaviour > > > There are a handful of open questions still in the RFC, but I wanted to > present an initial draft to start the discussion, because the current > behaviour is quite hard to explain in a short e-mail. > > Please let me know your thoughts. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I have mixed feelings about this. Reading just the email gives me the impression of an unimaginable BC Break with the potential of holding back PHP upgrades A LOT. But reading the RFC, it is pretty clear that what we have now is a consequence of entropy and what is being proposed is to explicitly make a plan with all existing cases in mind. The fix for the BC is something trivial: null was implicit but now will require explicitness. The behavior which makes existing code work seems easy to get in place. However, the amount of code that would need this and the fact that Rector is not used by every PHP Developer is something that makes this a big deal. The thing I like the most about the proposal is making a sensible choice to cover the scenarios that are intertwined. Considering what has been said about opt-in making things harder with no desired mass adoption, perhaps what could be done instead is an easy-way-out (opt-out). An attribute that can be added to the class and have it automatically default untyped uninitialized properties to null. This allows the original proposal to stand and allow for a wide adoption while still giving a way-out for computer systems written 30~15 years ago that are still running and still being slowly refactored / rewritten. One thing to make it explicitly clear about my suggestion, I don't want or intend to have an attribute that keeps the current engine as-is + develop the engine with the new behavior because in my mind that could mean multiple areas of the engine and it could be quite complex to handle. My proposal is more about an ad-hoc self-contained Annotation that simply goes through the class and automatically set everything to null before the engine does its thing. In a way, it could still be a BC-break no matter what - 2 different behaviors of the language, but I'm thinking that such attribute could make things behave as-is 99% of the time and allow legacy systems to still breathe. -- Marco Deleu
