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