On Mon, Nov 20, 2023, at 9:00 PM, Lanre Waju wrote:
> 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?
That's part of the point. Literally every feature added to a system (PHP or
otherwise) has some maintenance overhead associated with it. It may be small,
it may be huge, it may be worth it, it may not be worth it, but it's always
non-zero.
As for what a static class is, from your description I am understanding it to
mean this:
static class Foo {
public function beep(): string { ... }
public function boop(): string { ... }
}
Is effectively a shorthand for:
class Foo {
public function __construct() { throw new \Exception("You can't do that"); }
public static function beep(): string { ... }
public static function boop(): string { ... }
}
Much the same way a readonly class is. Is that understanding of the intent
more or less accurate?
>>> 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.
Cultural side note: At least in the US, where I am, "Mr. Firstname" is pretty
much never used except with some families that teach their children to use that
with adults. It's not necessary and kind of weird. "Mr. Garfield" if you want
to be formal is fine, or just Larry, or Crell, as that's the handle I use
virtually everywhere and there are people who know me as that more than as
Larry. (I am not offended, just noting a cultural mismatch point.)
>> 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.
There is no need to dumb it down, just to read what I actually wrote. *Every*
feature added has implications for future features added. Data and Sealed
classes are ideas that have been floated but never to a full RFC, but may end
up as an RFC in the future. They were convenient examples of future work that
would be impacted by adding a static keyword to classes, as those RFCs would
have to determine how to interact with static classes. Maybe the solution
would be simple, maybe it wouldn't, I have no idea. It is just an example to
show that the cost of adding a feature is never zero, and so the "if you don't
like it don't use it, so you're always wrong for voting against an RFC"
argument is nonsensical and disingenuous.
>> 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.
Funny you should mention it, in fact. One of the systems I maintain at work
currently is using an older version of Stripe's authentication library, which
is written as all static calls. That makes them unmockable. That sucks
horribly, because that means when our test suite runs we're sending *thousands
of auth calls* to Stripe, because there is no way to mock out that call with a
no-op, when we don't actually care what Stripe does in 99% of those tests.
We're currently in the process of upgrading to a newer version of the library
that has a proper instantiated service object instead of global static calls,
which will allow us to properly mock it, and save Stripe tens of thousands of
API hits per day and us probably multiple minutes on every test run. But it's
a slow process, and taking a lot of time/money to clean up.
*This is why static APIs are bad*. That's not just me making stuff up, this is
a well-understood principle around anyone who's done any serious work with unit
testing. It's easily the #1 argument people use against Laravel, which also
does a lot of static APIs and is, guess what, extremely hard to test properly
as a result.
A language-level feature that explicitly endorses and encourages those
all-static APIs (which is what is being proposed) would actively encourage code
like that Stripe library, which is wasting time, money, and network traffic for
us literally every single day. We should be discouraging that design, not
encouraging it.
>>> 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.
See above.
(sarcastic sniping removed)
> I am still holding out for a productive conversation based on facts,
> regardless, you are entitled to your opinions on the matter.
That static methods make unit testing harder and sometimes impossible is a
fact. That is not an opinion, it is an objective fact.
Language features that encourage making testing harder are bad features.
That's the long and short of it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
