Skip to content

Using typed properties on public/protected properties #43600

@nicolas-grekas

Description

@nicolas-grekas

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions