[PHP-DEV] [RFC] Static class

Stephen_Reay · June 27, 2024, 7:25am

On 27 Jun 2024, at 13:11, Mike Schinkel mike@newclarity.net wrote:

On Jun 27, 2024, at 12:09 AM, Stephen Reay <php-lists@koalephant.com> wrote:

Hi Mike,

To answer your question: I believe abstract static should be allowed, because the “objection” mis-characterises a particular aspect of them as an unintended consequence, when there’s evidence to show that’s not that case.

Claude essentially dismisses the use of abstract static methods:

only consequences of their intended meaning on non-static class

In v5.2 a strict standards notice was added regarding the use of abstract static methods in classes. No notice was ever shown when they’re used in interfaces. In v7 this notice was removed (via https://wiki.php.net/rfc/reclassify_e_strict#abstract_static_methods) because, as Nikita noted at the time:

Thank you for elaborating.

We are on the same page here as I too think abstract static should be allowed when declaring a class

We currently allow the use of abstract static functions in interfaces, as such it is inconsistent to not allow them as abstract methods. By using late static binding a method in the abstract class can reasonably depend on the existence of a static method in a superclass.

That to me says this is an intended feature, and not an unintended consequence.

Before I address this and your other comments, please understand that I do not see this as a huge issue either way, but I do want my argument to be understood. If my argument on this does not win the day, I will not lament it in any way.

As an aside, I had never seen interfaces used that way and found it surprising. Obviously I missed when Nikita made that claim.

As for “an intended feature, and not an unintended consequence,” when I was in university they drilled the idea of a sunken cost into me to the point I am a true believer. IOW, make the best decision moving forward vs. doubling down on bad decisions.

Note that I am not saying Nikita’s was a bad decision (or a good one) just that the existence of a prior decision should not color making the best decision moving forward.

I understand that, but I also think there is much value in consistency. If static methods (and abstract static methods) are supported, they should be supported consistently. There have been numerous RFCs passed that bring consistency (and thus remove developer surprise) to the language, even on features that some voters dislike so much, they’d rather the feature is intentionally difficult to use, to discourage use by other people (remember the trait constants RFC?)

I am curious, do you know of real-world userland code that is actually configured as your example that would be negatively affected by disallowing static methods calls?

Not in that specific case, no. I’ve seen some that uses abstract class as a poor mans static class (just to prevent instantiation) but not that uses abstract to allow omitting an upstream method.

On Jun 26, 2024, at 4:26 AM, Stephen Reay <php-lists@koalephant.com> wrote:

This is an example of code that works today (and all the way back to 5.0): https://3v4l.org/4EKo2

The class hierarchy embody the type of classes this RFC is about: only static members, no instantiation.

The implemented methods can be called statically, regardless of whether the class they’re implemented in is abstract or not. The abstract methods cannot be called directly.

Understood, but I do not see how interfaces or instantiation or abstract method are relevant to the discussion. They all seem orthogonal to me.

A class cannot contain abstract methods if it is not also marked as abstract. That’s the whole point. If you prevent a static class from also being abstract, you prevent that class from partially implementing an interface (or parent class with abstract methods).

So these classes would be a candidate for the static class keyword (or Attribute) - except they can’t, if calls to implemented methods on abstract classes are disallowed. Because the Base::a() method has been publicly callable, for potentially as long as 20 years next month.

While it may be true that it has been that way, disallowing static methods from being called using abstract static classes would not be a BC break because it was previously impossible to declare a class as static let alone abstract static.

Right so I’m not actually saying this is a BC break itself - I’m saying the authors of the library/code then can’t adopt the static keyword, which embodies their intent fully, because if they do so their code has a BC break (code that was previously callable, it not any more).

Further, there are often new features with constraints that result in developer not being “to do what they have been able to do for 20 years” because, looking forward, those constraints make more sense than not having those constraints.

Take a look at readonly properties. They must be typed, but I could have used the same argument against that saying “We’ve always been able to have untyped properties so readonly should not have to be typed.”[1] I’d say requiring them to be typed was a win, though, regardless of past property capabilities.

I don’t think the reason something has limitations should be ignored. It’s not like Nikita said “we should disallow untyped properties because otherwise we have to allow them forever”. It was specifically to prevent confusion due to the implicit null default on untyped properties. Also, this restriction was quite easy to work around, thanks to the mixed type introduced in 8.0.

I’m not claiming necessarily that disallowing calling static methods on a abstract static class is a best practice, but I am saying that “we’ve been able to do it with similar syntax for a long time” is not a particularly compelling argument if disallowing is a better approach.

As another aside, assuming everyone agrees on what a best practice is for a given case, I doubt anyone would object to a constraint that forced developers to follow that best practice vs. allowing them to write less ideal code.

My point here is that if someone wants to prohibit calling public static methods on abstract classes with the static keyword, that’s going be inconsistent with how it’s worked for the last 20 years (i.e. on classes that were ‘static’ in intent but not syntactically),

Back to sunken cost, does it make more sense to only give developers who want to disallow using static methods for their abstract static classes access to @internal docblock — which I argued against elsewhere in this thread — and let Hyrum’s Law take over, OR do we enable them to disallow calling those static methods from the abstract class itself?

More importantly, IF we do not immediately disallow calling static methods on abstract static classes then we will never be able to disallow in the future, because of BC. But on the flip side we could later open them up for calling if we found the limitation to be problematic.

or if it applies the change everywhere it’s going to be a BC break.

And to be clear, I am against BC breaks in almost all cases. So bringing that up between us is moot.

All that said, if you tell me "I don’t care about closing the door on being able to disallow developers from calling static methods on abstract static methods because prior to abstract static classes static methods could be called on abstract classes in the past" I will respect that, and as I said above, it won’t bother me.

Don’t care is the wrong term I think. As I’ve said, numerous times, I’m concerned about consistency first and foremost. If the voting powers that be deem calling a static method on an abstract class (regardless of the class’s other modifers/keywords) is too much of a pearl clutching moment, and it’s deprecated, I’ll probably ask pretty loudly “why, what actual problem does this prevent” but I’ll appreciate that it’s being consistent, despite the BC break.

My only reason for persisting is to ensure that the argument I was making was understood before it was dismissed.

I think I understand your view: you’re not as concerned with consistency if the alternative is something “better”.

-Mike

[1] Ignoring there were technical issues with allowing untyped to be readonly, which could have been gotten around somehow if the consensus was “They must be able to untyped.”

Cheers

Stephen

Mike_Schinkel · June 27, 2024, 7:32am

On Jun 27, 2024 at 3:26 AM, <Stephen Reay> wrote:

I think I understand your view: you’re not as concerned with consistency if the alternative is something “better”.

That yes, but more importantly, that deciding NOT to disallow calling static methods on abstract static classes is a decision for the ages that cannot be reversed later because of BC.

And with that, I think we’ve both beaten this horse to death so I am over and out on this topic.

-Mike

Tim_Dusterhus · June 27, 2024, 6:11pm

Hi

On 6/24/24 09:53, Ayesh Karunaratne wrote:

Personally, I think this will be a useful feature. Just like we have
`readonly` properties and `readonly` classes, I don't see why we can't
have static methods. I also saw in the draft PR that it does not
require a lot of changes to the engine to have this.

I'd like to propose to add some more information and points addressed
in the RFC. This is of course merely a suggestion, but it's something
I was thinking when reading the RFC.

- Why is it a class-level flag and not an attribute (similar to the
`#[Override]` attribute in PHP 8.3) ?

To quote myself from the #[\Override] RFC:

This RFC proposes an attribute instead of a keyword, because contrary to other modifiers (e.g. visibility) that are part of the method signature, the attribute does not affect behavior or compatibility for users that further extend a given class and neither does it affect users that call the method. It is purely an assistance to the author of a given class.

Marking a class as 'static' *does* affect how the class may be used and thus the static-ness is part of the public API. Therefore it should be a keyword. Everything else would also be inconsistent with final classes effectively making all members final and readonly classes making all members readonly.

- Can a subclass extend a static parent class without using the
`static` keyword in the subclass? This will avoid a lot of BC issues
if a library decides to declare classes as static.

It should not. See: readonly classes. I also believe that static classes should be implictly final. Given that no objects of such a class can exist, they cannot be exchanged by a different class anyways and inheritance is not meant for code reuse.

Best regards
Tim Düsterhus

Tim_Dusterhus · June 27, 2024, 6:31pm

Hi

On 6/25/24 10:41, Stephen Reay wrote:

Like I said, I much prefer the keyword syntax - but I also recognise that others may have different priorities in terms of supporting older language versions, which is why I think that aspect is worth consideration (perhaps a secondary vote, or an informal vote to gauge consensus?), because too many good RFCs get rejected over small details.

Syntax is absolutely not a small detail. It's the most user-visible part of a language feature that is not just a new part in the standard library. And that is probably the reason why it's the most hotly debated part of any new language feature that is proposed.

As said in my previous email, I strongly oppose inventing new syntax and instead borrow syntax from existing (related) features as much as possible. An example that comes to my mind would be the initial brace-based syntax for the clone-with RFC that has since been replaced by array-style syntax that should be immediately understandable by any PHP programmer. PHP should continue to look and feel like PHP.

Best regards
Tim Düsterhus

Tim_Dusterhus · June 27, 2024, 6:24pm

Hi

On 6/25/24 05:17, Stephen Reay wrote:

and I'd rather have the feature with slightly odd syntax rather than not at all.

Absolutely not. PHP is already odd enough as it is. We should not add additional oddness in the interest of pushing a new screw-shaped feature in with a sledgehammer. Any additional oddity makes it harder for Junior developers and developers coming from a different language to learn PHP and also required the developer to learn the language details by heart instead of being able to rely on their intuition.

I'm already leaning towards "Don't want static classes", but if they use an attribute instead of a keyword, then it's going to be a clear "no". See also my email in response to Ayesh.

Best regards
Tim Düsterhus

PS: Can you please cut the quoted parts to a minimum instead of including the original email in full? That makes it much clearer to see what part you are actually replying to and reduces the amount of storage requiring for all the thousands of ML subscribers

Lanre · June 27, 2024, 10:36pm

On Thu, Jun 27, 2024 at 1:18 PM Tim Düsterhus <tim@bastelstu.be> wrote:

It should not. See: readonly classes. I also believe that static classes
should be implictly final. Given that no objects of such a class can
exist, they cannot be exchanged by a different class anyways and
inheritance is not meant for code reuse.

I don’t agree that they should be implicitly final, or that inheritance is not meant for code reuse. It is currently possible eg: https://gist.github.com/oplanre/6894f56fb61134ee5ea93cf262ba3662 and I don’t see why that should change, unless you have any solid reasons as to why.

Lanre

Mike_Schinkel · June 28, 2024, 12:43am

On Jun 27, 2024, at 2:11 PM, Tim Düsterhus <tim@bastelstu.be> wrote:
Marking a class as 'static' *does* affect how the class may be used and thus the static-ness is part of the public API. Therefore it should be a keyword. Everything else would also be inconsistent with final classes effectively making all members final and readonly classes making all members readonly.

Very insightful; that is a great rule of thumb.

I also believe that static classes should be implictly final. Given that no objects of such a class can exist, they cannot be exchanged by a different class anyways

I object here.

There are functions in classes that I have built in the past that are static and also benefit from inheritance. Could they be called directly on the base class; yes? But that is less elegant and increases complexity with two levels of inheritance are needed.

Specifically the functionality I am thinking of is the base class is generic functionality for factory functions and then child factory functions implement use-case specific logic for the type of the object produced. For example, each of these functions has a MakeNew(...) function, and children call self::MakeNew(...).

Base
-- Term
-- User
-- BasePost
-- Post
-- Page

That is a subset of classes I used, and those classes were designed for use with WordPress.

Further, these classes implemented "hooks" in WordPress. Using inheritance allowed all the hooks to be managed without repeating them in many places, being able to modify them for a class-specific need, and also without accidentally forgetting to add them.

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.

So I would really hate to finally get static classes but still not be able to use them as intended for select use-cases only because someone decided without knowing all applicable use-cases that they did not like the idea of people using inheritance.

-Mike

Lynn · June 28, 2024, 7:05am

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?

Stephen_Reay · June 28, 2024, 6:04pm

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

Lanre · June 28, 2024, 5:07pm

On Fri, Jun 28, 2024 at 1:05 AM 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?

Sounds like a ‘you’ problem. Can you go into more details about said subtle bugs? With examples if possible?

Lanre

Lynn · June 28, 2024, 7:02pm

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.

Bilge · June 28, 2024, 7:29pm

Hi Tim,
On 27/06/2024 19:24, Tim Düsterhus wrote:

On 6/25/24 05:17, Stephen Reay wrote:

and I'd rather have the feature with slightly odd syntax rather than not at all.

Absolutely not. PHP is already odd enough as it is. We should not add additional oddness in the interest of pushing a new screw-shaped feature in with a sledgehammer. Any additional oddity makes it harder for Junior developers and developers coming from a different language to learn PHP and also required the developer to learn the language details by heart instead of being able to rely on their intuition.

Don't worry, I couldn't bring myself to seriously entertain using an attribute instead of a keyword. I'll update the RFC to include it as a rejected feature.

I'm already leaning towards "Don't want static classes"

Why? It is important to understand what your misgiving are in case there anything we can do to assuage them.

Cheers,
Bilge

Benjamin_Aussenhofer · June 28, 2024, 8:58pm

On Mon, Jun 24, 2024 at 1:15 AM Bilge <bilge@scriptfusion.com> wrote:

Hi Internals!

I am pleased to present my first RFC: Static class
<https://wiki.php.net/rfc/static_class>.

This work is based on the previous discussion thread on this list of the
same name, and hopefully captured all the relevant details,
notwithstanding anything unanticipated that may present itself during
the implementation. Let me know if you feel anything important has been
missed. I am aware it omits to mention specifics about messages so
emitted when runtime or compile-time errors occur, but I anticipate this
can be hashed out in the PR, unless consensus indicates otherwise.

I am aware this idea is not supported by everyone, but there seemed to
be enough positive voices for it to be worth a shot. I’d like to get a
better idea of where people might stand when it comes down to a vote,
now there is a formal RFC, so we know whether it’s worth completing the
implementation, although any sentiments so proffered are of course not a
commitment to vote any particular way and nobody should feel compelled
to speak to that unless comfortable. Looking forward to feedback!

while i wouldn’t ordinarily find a lot of use-cases for myself for this, i think its consistent with final and readonly to allow static on classes as well. The code I believe would be mostly at compile time anyways to do these checks, except for new $class.

So in general I would vote yes for this, if all edge cases are clear and considered.

Cheers,
Bilge

Bilge · June 29, 2024, 3:56pm

I believe Tim already answered this, and I understood his reasoning to be that keywords are used when they modify behaviour in a way that is meaningful for the consumer of that class. Or to put it another way, attributes are purely informational. For me personally, introducing an attribute never crossed my mind, and since we already have the keyword in the language performing a similar function in PHP, and other languages already, it seems nonsense to contemplate anything else. No, a static parent implies a static child, but implied or not, it must still be specified explicitly. I may need to clarify that in the RFC, so thanks for the question. Not sure what you mean exactly, but if you mean, can a static subclass suddenly become non-static, the answer is no.

···

Hi Ayesh,

On 24/06/2024 08:53, Ayesh Karunaratne wrote:

 - Why is it a class-level flag and not an attribute (similar to the `#[Override]` attribute in PHP 8.3) ?

 - Can a subclass extend a static parent class without using the
`static` keyword in the subclass? This will avoid a lot of BC issues
if a library decides to declare classes as static.

 - Are there any opt-out mechanisms for subclasses?

Again thanks for the question, as this is also something I had no previously considered.

 - Can you mark interfaces, abstract classes, and Enums as static?

It seems others avoided addressing this question, and honestly I was not really sure where to go with this one. What would it mean for an enum to be static? I thought the whole point was we can type a group of values, but static classes have no meaning within the type system, so I cannot see the application.

As for abstract classes, the current version of the RFC (1.2) now declares static mutually exclusive with abstract, so the answer there is also no.

For interfaces, I haven’t given this a great deal of thought. In principle I don’t think a static interface is especially useful, but I could be wrong about this. Nevertheless, it is not something I intend for this RFC, since even just static classes already have their detractors, and expanding its scope any further is probably placing it further in danger of rejection. So for now, the answer is also no, but static interfaces seem like a reasonable extension to this work if there is interest in future.

Cheers,
Bilge

Tim_Dusterhus · June 30, 2024, 2:31pm

Hi

On 6/29/24 17:56, Bilge wrote:

- Why is it a class-level flag and not an attribute (similar to the `#[Override]` attribute in PHP 8.3) ?

I believe Tim already answered this, and I understood his reasoning to
be that keywords are used when they modify behaviour in a way that is
meaningful for the consumer of that class. Or to put it another way,
attributes are purely informational. For me personally, introducing an

You understood that correctly.

The forward compatibility argument brought forward by the other participants is not really useful either, because consider the following:

     #[StaticClass]
     class Foo {
         public static function myFunc() { }
     }

     class Bar extends Foo {
         public function myNonStaticFunc() { }
     }

This would work fine in PHP 8.3, but break when upgrading to PHP 8.4! By using a keyword it is guaranteed that the code only runs on PHP versions that will reliably enforce all the constraints, preventing this gotcha during a PHP version upgrade.

Best regards
Tim Düsterhus

Tim_Dusterhus · June 30, 2024, 3:10pm

Hi

On 6/28/24 21:29, Bilge wrote:

I'm already leaning towards "Don't want static classes"

Why? It is important to understand what your misgiving are in case there
anything we can do to assuage them.

I don't see value in being able to explicitly mark a class as `static` for the reasons that have already been brought forward by other participants (such as Larry).

But more importantly, the RFC and discussion so far don't really convince me that any of the participants in favor of static classes really know what they want and thought about *all* the implications of that.

I strongly favor an opinionated RFC where the RFC author did their research and makes it clear why the proposal is the right choice and backs this up by proper arguments. Of course this doesn't mean that the RFC author should not listen to the list discussion, but the high level details should be clear right from the beginning. As of now the RFC still has some open questions regarding "core functionality" and even intents to leave them as a secondary vote.

In other words, too many cooks spoil the broth.

Given the upcoming feature freeze, the current list volume and core folks being busy with finishing up and polishing their own RFCs for PHP 8.4, the timing doesn't really help getting the necessary attention towards your RFC either. I might be more receptive towards a quieter period of the year, where I can take the time to really think about the RFC, like I do for other RFCs as well. My earlier responses towards the Lazy Objects RFC might be a good example towards the level of detail I try to give RFCs. Even when I don't personally understand them or don't see myself using them (yet), I want a best-possible result that will not cause sadness 3 years down the road.

Best regards
Tim Düsterhus

Mike_Schinkel · July 1, 2024, 1:54am

On Jun 30, 2024, at 11:10 AM, Tim Düsterhus <tim@bastelstu.be> wrote:
I strongly favor an opinionated RFC where the RFC author did their research and makes it clear why the proposal is the right choice and backs this up by proper arguments. Of course this doesn't mean that the RFC author should not listen to the list discussion, but the high level details should be clear right from the beginning. As of now the RFC still has some open questions regarding "core functionality" and even intents to leave them as a secondary vote.

With respect, I completely support your right to choose what you favor.

However, I would like to suggest there might be some negative consequences to your approach and request that you reconsider your what you favor.

Yes, if an RFC author does their research and makes it clear why the proposal is the right choice and backs this up by proper arguments then it makes for a better RFC which can more easily be reviewed.

OTOH, it limits the pool of RFC authors who can successfully achieve that bar to only those who know what research needs to be done and which arguments resonate well resonate with list members. Effectively it limits the successful pool of RFC authors to the list of prior successful RFC authors who — through experience — have developed enough knowledge about what research needs to be done and which arguments resonate well with list members.

Yes someone can overcome these experience barriers by submitting numerous RFCs that fail and over years of time eventually gain enough knowledge and experience to succeed, but realistically how many people will go through that gauntlet?

The problem with the approach is there over time there becomes is a diminishing number of individuals who can and will submit RFCs, and the language slowly dies:

Currently the culture of this list is people submit an RFC and if they can endure the crucible to come out the other side their RFC may be adopted. But few can endure that crucible. Further, brainstorming on the list — as recent evidence has shown — is effectively impossible.

The experienced RFC submitters know to go off list and work with other experienced RFC submitters to prepare an RFC prior to having to endure an onslaught of criticism from this list. The problem for new RFC writers is they don't know who to ask nor have the clout to approach people to get such collaborators.

IMO it would be better if the culture here approached would-be RFC writers differently. I instead experienced RFC writers provided a bit of mentoring to new RFC writers, encourage them to cultivate their ideas in a version-controlled repo off this list, but also have the mentor call for list members to collaborate with the would-be RFC writer in a discussion forum on their repo. Once those collaborators feel the RFC is fully-baked then they could present to the list.

If that culture existed, your strongly favored well-researched and clearly-argued RFC could be the norm rather than the exception.

Food for thought?

-Mike
P.S. I currently have a repo for an RFC where I want to make a call for collaboration, but I do not know how to call for help on the list without attracting those who would immediately swarm the discussion forum to flood the channel with criticism before the ideas are even fully baked.

Bilge · July 7, 2024, 7:58pm

On 30/06/2024 16:10, Tim Düsterhus wrote:

I strongly favor an opinionated RFC where the RFC author did their research and makes it clear why the proposal is the right choice and backs this up by proper arguments. Of course this doesn't mean that the RFC author should not listen to the list discussion, but the high level details should be clear right from the beginning. As of now the RFC still has some open questions regarding "core functionality" and even intents to leave them as a secondary vote.

In other words, too many cooks spoil the broth.

I won't pretend I had the knowledge and experience to tackle this alone. I stood on the shoulders of giants to make this PR possible, and even before PR, I didn't have a clear view when I first casually strolled into internals. Talking to the experts here helped me find the words I was searching for and ensure edge cases were considered. That said, I hope you don't think me soft, this was not a design by committee; the RFC is a product of my own work and the decisions now made are a result of my own convictions, bolstered but not coerced by the input of others. Moreover, now the RFC is finished at version 1.3, I am very proud of what it has become and stand by every implementation decision made pertaining to specific semantics; I am convinced they are correct and would not benefit from any further modification, with the benefit of experience writing the implementation behind me. I hope you, too, are equally convinced if you would now humble me with another read.

Kind regards,
Bilge

Bilge · July 7, 2024, 8:08pm

On 24/06/2024 00:10, Bilge wrote:

Hi Internals!

I am excited to announce the final implementation for Static Class is ready for review at <https://github.com/php/php-src/pull/14861> and includes a brief summary of the key semantics of the feature.

Furthermore, the 1.3 (presumed) final version of the RFC is now published at <PHP: rfc:static_class.

Naturally, if there are any further weighty comments or criticisms to be levied against either one of these, they may still be subject to changes as appropriate.

Tomorrow the minimum period elapses before the vote may be started. Discussions on this topic have been quiet for about a week as well, so if there are no major concerns outstanding, I expect to announce the vote to start very soon.

Kind regards,
Bilge

Mike_Schinkel · July 8, 2024, 12:16am

On Jul 7, 2024, at 4:08 PM, Bilge <bilge@scriptfusion.com> wrote:

On 24/06/2024 00:10, Bilge wrote:

Hi Internals!

I am excited to announce the final implementation for Static Class is ready for review at <https://github.com/php/php-src/pull/14861> and includes a brief summary of the key semantics of the feature.

Furthermore, the 1.3 (presumed) final version of the RFC is now published at <https://wiki.php.net/rfc/static_class>.

Congrats on getting it to this point.

I support this in all but the RFC’s restriction on abstract, as I have previously mentioned on the list.

-Mike

Naturally, if there are any further weighty comments or criticisms to be levied against either one of these, they may still be subject to changes as appropriate.

Tomorrow the minimum period elapses before the vote may be started. Discussions on this topic have been quiet for about a week as well, so if there are no major concerns outstanding, I expect to announce the vote to start very soon.

Kind regards,
Bilge