Hi
On 6/24/24 09:53, Ayesh Karunaratne wrote:
Personally, I think this will be a useful feature. Just like we have
`readonly` properties and `readonly` classes, I don't see why we can't
have static methods. I also saw in the draft PR that it does not
require a lot of changes to the engine to have this.
I'd like to propose to add some more information and points addressed
in the RFC. This is of course merely a suggestion, but it's something
I was thinking when reading the RFC.
- Why is it a class-level flag and not an attribute (similar to the
`#[Override]` attribute in PHP 8.3) ?
To quote myself from the #[\Override] RFC:
This RFC proposes an attribute instead of a keyword, because contrary to other
modifiers (e.g. visibility) that are part of the method signature, the
attribute does not affect behavior or compatibility for users that further
extend a given class and neither does it affect users that call the method. It
is purely an assistance to the author of a given class.
Marking a class as 'static' *does* affect how the class may be used and
thus the static-ness is part of the public API. Therefore it should be a
keyword. Everything else would also be inconsistent with final classes
effectively making all members final and readonly classes making all
members readonly.
- Can a subclass extend a static parent class without using the
`static` keyword in the subclass? This will avoid a lot of BC issues
if a library decides to declare classes as static.
It should not. See: readonly classes. I also believe that static classes
should be implictly final. Given that no objects of such a class can
exist, they cannot be exchanged by a different class anyways and
inheritance is not meant for code reuse.
Best regards
Tim Düsterhus
