Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121735
Message-ID: <d08dffeb-3503-4d60-8451-b1ce5f812549@online-presence.ca>
Date: Mon, 20 Nov 2023 14:00:09 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: internals@lists.php.net
References: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca>
 <B6359F06-6864-4DE8-84CE-2558520E3B18@gmail.com>
 <ad169242-e52e-42d1-aa0d-c4d36cc566da@app.fastmail.com>
Organization: Online Presence
In-Reply-To: <ad169242-e52e-42d1-aa0d-c4d36cc566da@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC Proposal - static modifier for classes
From: lanre@online-presence.ca (Lanre Waju)

I will have to disagree with everything you said:

I outlined what a static class would be: A class that cannot be 
instantiated in which all members are implicitly static. We already have 
static members, so please elaborate on the maintenance burden that 
adding static to a class as that could help explain better, i mean what 
feature doesn't have technical debt associated with it? The new JIT engine?

>> 3. It is entirely opt-in. If you hold reservations about using static
>> classes, you can simply choose not to use them.
> This is a spurious and disingenuous argument, even if it gets trotted out frequently on many RFCs.  I'm not picking on you in particular here, but it's a bad argument to use, period, 99% of the time, no matter who is saying it.
If you insist, Mr. Larry.

> Similarly, if we add a static marker to classes, that means all future improvements to classes need to consider "but what if the class is static?"  Eg, there was discussion a while back about `data` classes.  What happens if you have a `static data class`?  Is that a syntax error?  Does it work?  If it works, what does "work" mean?  What about sealed classes?  Can you have a sealed static class?  What would that mean?  Those are questions that would need to be answered, because this feature exists.
Either i'm in an alternate reality where the data classes and sealed 
classes rfcs passed, or I've just been straw-manned. Either way, is it 
really that difficult to decide on as a community what a static data 
class implies? We have already established that a static class means all 
the members are static, but i can try to dumb it down for you if need be.

> It impacts all users, too, because almost no one builds a 100% self-written codebase anymore.  99% of projects are 80% someone else's code via Composer packages large and small, which means every language feature they use, you need to be aware of how to use.  If some library has a static class as part of its API, I am now forced to work with static classes, whether I like it or not.
If you had told me we were allowed to pull numbers out of our asses, i 
would have mentioned that 100% of php users will benefit from this, 
Including people like you who don't necessarily see the value in it. As 
a user of a class, it shouldn't matter whether it's static or not, the 
static members will be the same as using a normal class with static 
members, in fact, people already simulate this in userland by making 
__construct private and only using static members, does that impede your 
ability to use such libs? How is this forcing you to use static classes? 
The dev of said library(which no one is forcing you to use) would be the 
one who made that call. After which it's your call to decide whether or 
not the library suites you. I don't see any forcing here but do 
enlighten me.

>> The proposal is designed with the intention of improving code clarity,
>> reinforcing design principles, and establishing a clear and standardized
>> approach to expressing the intended usage of a class. While I advocate
>> for member properties and methods to be implicitly static, I am open to
>> understanding alternative viewpoints on why this might not be the
>> optimal choice.
> Emphasizing:
>
>> reinforcing design principles,
> Which is exactly the problem.  All-static classes *are a bad design principle that should not be encouraged*.  They're a namespace cheat, not a good design.  They should be discouraged, not encouraged.

They could be used as a namespace cheat yes, they could be used wrongly, 
but that doesn't mean it doesn't have any valid uses or make it 
inherently bad. You remind me of the people that literally never use 
inheritance because they read "inheritance over composition" somewhere. 
Please elaborate more on why it's a bad design principle.

> If the methods are pure functions, then they really ought to just be namespaced functions.  Those work.  They're fine.  Autoloading is frankly mostly solved by using the `files` block in your composer.json's autoload config, and then you don't need to care.  Pure functions are OK.  The obsession with avoiding functions in many parts of PHP culture is really not to its credit.  (And I admit going through my own phase where I thought that; it was incorrect then, it's incorrect now, and it's been incorrect pretty much since 5.5 gave us an always-on opcache.)
> If the methods are non-pure... then it has no business being a static method.  It needs to be an object method, otherwise it breaks testing.  Yes, there are a lot of older libraries and APIs that use static methods in a stateful way, or make IO calls to a remote service, etc.  Those libraries are wrong.  Period.  Language features that encourage that anti-pattern are anti-features.  Those should be instantiated objects which can be injected and mocked and use mocks and be tested easily and so on.

Again that is your opinion, yet you speak it like it's fact. I guess all 
those libraries are wrong because Mr. Larry thinks so. So before you 
write your next library, ask yourself "what would larry do".

> If we really wanted the language to reinforce good design principles, we would make a class that has only static methods and nothing else a syntax error. :-)  I do not proposed we actually do that, but that's what "reinforcing design principles" would mean in practice.
And i guess you are also the authority in terms of what design 
principles should and shouldn't be reinforced, I will also keep that in 
mind.

I am still holding out for a productive conversation based on facts, 
regardless, you are entitled to your opinions on the matter.

Cheers,

Lanre.


On 2023-11-20 12:59 p.m., Larry Garfield wrote:
> On Mon, Nov 20, 2023, at 7:52 AM, Rowan Tommins wrote:
>> On 19 November 2023 21:28:08 GMT, Lanre Waju <lanre@online-presence.ca> wrote:
>>> Hi, similar to the abstract and readonly modifiers to classes (similar in syntax only), I propose a class level "static" modifier that ensures:
>>
>> Hi Lanre,
>>
>> There was a proposal for this several years ago which was declined at
>> the voting stage: https://wiki.php.net/rfc/abstract_final_class
>>
>> That doesn't mean we can't look again, but any new proposal would need
>> to at least address the reasons the previous one was declined. I
>> believe these are the relevant discussion threads:
>> https://externals.io/message/79211 https://externals.io/message/79338
>> https://externals.io/message/79601
>>
>> My memory is that one of the main points against was that a class with
>> only static methods is just a namespace, and you can already put
>> functions directly in a namespace. The only issue being that we don't
>> have good autoloading support for such functions, and that's a whole
>> different problem...
> I wasn't a voter at the time, but I would absolutely vote against a `static class` RFC today, for largely the same reasons.
>
> On Mon, Nov 20, 2023, at 8:35 AM, Lanre Waju wrote:
>
>> 3. It is entirely opt-in. If you hold reservations about using static
>> classes, you can simply choose not to use them.
> This is a spurious and disingenuous argument, even if it gets trotted out frequently on many RFCs.  I'm not picking on you in particular here, but it's a bad argument to use, period, 99% of the time, no matter who is saying it.
>
> Rowan already mentioned the maintenance burden that it entails.  I'll go a step further.  We've already seen that "readonly" properties have their uses, though not everyone uses them.  So far so good.  But readonly also was implemented with a stealth extra asymmetric visibility implication, which made the design and implementation of real asymmetric visibility harder, and very likely contributed to that RFC not passing due to the perceived extra complexity of working around readonly's shortcomings.
>
> Similarly, if we add a static marker to classes, that means all future improvements to classes need to consider "but what if the class is static?"  Eg, there was discussion a while back about `data` classes.  What happens if you have a `static data class`?  Is that a syntax error?  Does it work?  If it works, what does "work" mean?  What about sealed classes?  Can you have a sealed static class?  What would that mean?  Those are questions that would need to be answered, because this feature exists.
>
> It impacts all users, too, because almost no one builds a 100% self-written codebase anymore.  99% of projects are 80% someone else's code via Composer packages large and small, which means every language feature they use, you need to be aware of how to use.  If some library has a static class as part of its API, I am now forced to work with static classes, whether I like it or not.
>
> Certainly, many features are worth the extra burden to maintain and to train for.  We pass new RFCs all the time that we collectively decide are worth it, I've proposed several, etc.  But "if you don't like it, just ignore it" has always been a misleading and ignorant claim to make about any proposed feature.  "The implications are small so you probably won't need to worry outside of these situations" is a valid argument to make (and to disagree about), but that's a different thing.
>
>> The proposal is designed with the intention of improving code clarity,
>> reinforcing design principles, and establishing a clear and standardized
>> approach to expressing the intended usage of a class. While I advocate
>> for member properties and methods to be implicitly static, I am open to
>> understanding alternative viewpoints on why this might not be the
>> optimal choice.
> Emphasizing:
>
>> reinforcing design principles,
> Which is exactly the problem.  All-static classes *are a bad design principle that should not be encouraged*.  They're a namespace cheat, not a good design.  They should be discouraged, not encouraged.
>
> If the methods are pure functions, then they really ought to just be namespaced functions.  Those work.  They're fine.  Autoloading is frankly mostly solved by using the `files` block in your composer.json's autoload config, and then you don't need to care.  Pure functions are OK.  The obsession with avoiding functions in many parts of PHP culture is really not to its credit.  (And I admit going through my own phase where I thought that; it was incorrect then, it's incorrect now, and it's been incorrect pretty much since 5.5 gave us an always-on opcache.)
>
> If the methods are non-pure... then it has no business being a static method.  It needs to be an object method, otherwise it breaks testing.  Yes, there are a lot of older libraries and APIs that use static methods in a stateful way, or make IO calls to a remote service, etc.  Those libraries are wrong.  Period.  Language features that encourage that anti-pattern are anti-features.  Those should be instantiated objects which can be injected and mocked and use mocks and be tested easily and so on.
>
> To be clear, static methods have their place.  I'm not against static methods.  I'm against static methods as a cheap discount-bin namespace, as that shows a lack of understanding of the language and of OOP design.  Yet that is precisely what `static class` would be.
>
> If we really wanted the language to reinforce good design principles, we would make a class that has only static methods and nothing else a syntax error. :-)  I do not proposed we actually do that, but that's what "reinforcing design principles" would mean in practice.
>
> --Larry Garfield
>