Re: [RFC] Static class

From: Date: Tue, 25 Jun 2024 02:22:07 +0000
Subject: Re: [RFC] Static class
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
> On Jun 24, 2024, at 3:53 AM, Ayesh Karunaratne <[email protected]> wrote:
> - Why is it a class-level flag and not an attribute (similar to the
> #[Override] attribute in PHP 8.3) ?

From my perspective that would create much confusion among every PHP developer who has not committed
to memory when to use static as a class keyword and when to use it as an attribute.

Given the concept already exists in keywords I would strongly argue that it makes no sense to
introduce as an attributes in core PHP.  

Attributes are great for concepts new to PHP, IMO, but not for existing concepts already part of PHP
implemented with keywords.

> On Jun 24, 2024, at 4:27 AM, Claude Pache <[email protected]> wrote:
> * The main purpose of the abstract keyword is to prevent a class to be
> instantiated, which (in case of static class) is more semantically described by the
> static marker. Beyond that, it just allows to declare a method that, if implemented by
> a subclass, should have a compatible signature. Most notably, it does not prevent the other static
> members of the class to be used directly.

Given a primary purpose for being able to declare a class static is to signal intent,
disallowing abstract static classes seems at odds with that goal.

Of course it is currently true that static methods of abstract classes can
be called from outside a  class and its class hierarchy, so if we allow declaring abstract
static classes then it would never in the future be possible to lock down calls of
static methods to those abstract classes.

So IMO it would be better to disallow calling static methods from outside a declared
abstract static class and its inheritance hierarchy as part of this RFC. That would be
backward compatible since there are currently no classes that are declared in that manner.  Doing
otherwise would force those who want to declare a class as both static and
abstract to have to make a choice rather than being able to signal their full intent.
Which brings us back to the "implied" vs. "explicitly declared" bifurcation I
mentioned in a prior email.

BTW, I am assuming it is technically possible to disallow calling methods for classes declared both
abstract and static without considerable difficulty in implementation and
without creating a significant drain on performance. 

-Mike 

P.S. I would argue the same for readonly static properties, but as that seems those
would require an involved discussion about the exact rules to implement I am demurring on that
topic.


Thread (71 messages)

« previous php.internals (#123801) next »