Re: [RFC] Static class

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