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 <la...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
