Re: [RFC] Static class
| From: | Lynn | Date: | Fri, 28 Jun 2024 19:02:53 +0000 |
| Subject: | Re: [RFC] Static class | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123994@lists.php.net to get a copy of this message | ||
On Fri, Jun 28, 2024 at 8:04 PM Stephen Reay <php-lists@koalephant.com>
wrote:
>
>
> On 28 Jun 2024, at 14:05, Lynn <kjarli@gmail.com> wrote:
>
>
>
> On Fri, Jun 28, 2024 at 2:48 AM Mike Schinkel <mike@newclarity.net> wrote:
>
>> >> and inheritance is not meant for code reuse.
>>
>> Just because code reuse in inheritance can be problematic it does not
>> have to be in all-cases. Moderation in all things. I used that approach for
>> 10+ years and never once had any of the problems people claim about using
>> inheritance for code reuse. This was likely because my needs were
>> constrained by the use-case and by nature did not grow out of control with
>> complexity.
>>
>
> My experience is the opposite. There are subtle bugs I keep running into
> with static function and properties causing unexpected behavior. I'm not
> against having static classes open by default for the sake of consistency,
> though my preference would be to avoid the headache altogether and just
> make them final by default so I won't ever have to deal with it. Would
> traits not solve the problem of horizontal reuse?
>
>
> Hi Lynn,
>
> I understand it's frustrating when there are bugs/unexpected behaviour,
> but wouldn't the (existing) *ability* to add the
final
> keyword to a class
> solve those issues for you, without preventing others from using the
> capabilities of parent/child class relationships?
>
>
> Cheers
>
>
> Stephen
>
The main issue is that it's easy to mess up by default and not messing up
requires you to understand why. I prefer defensive programming, close it
and only open when it's really required. If there's legit scenarios where
you need inheritance in a static context the requirement could be an "open"
keyword or removing it being final, we can't do it the other way around
without massive BC break.