-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Description
Right now, we added types to private/final/internal properties only because they're the only ones we can change without breaking BC.
For public/protected properties, adding a type breaks BC when a child class redeclares an existing properties. The reason is that redeclared properties must have the exact same type and their parent properties. Neither variance nor covariance is allowed for properties.
Since it'd still be nice to add types to them, can we draw a migration path?
The only path I see is to throw a deprecation when a child class redeclares a property.
The only reason I see for redeclaring a public/protected property is to change it's default value.
For non-static public/protected properties, it should always be possible to use the constructor if a different initial value is desired. As such, we could unconditionally throw a deprecation notice in DebugClassLoader
when an untyped non-static property is found. Alternatively, we could we make this deprecation opt-in, eg reusing @final
on properties, but I don't see the benefit of doing so since I anticipate that all such properties would have the annotation.
For static properties, I'm not sure I see a migration path. But where do we use public/protected static props in core? I can think of command names/descriptions. Those can already be replaces by attributes. So maybe the path forward is to turn them all into attributes? We'd need to investigate the codebase to have a clearer picture on that.