> On 24 Nov 2023, at 01:09, Rowan Tommins wrote:
>
> On Thu, 23 Nov 2023 at 14:20, Stephen Reay wrote:
>
>>
>> Out of the box, with no package manager or module loader or anything, you
>> can do as little as call `spl_autoload_register` with no arguments, and
>> have working class autoloadi
Seriously? Are you really this stupid or just feigning ignorance? How is
this a global:
class X {
private static $count = 0;
}
I am no longer pushing this RFC because idiots like you are in charge of
the votes but seriously your argument is dumb as fuck. If you aren't
sure then why say anythi
On Thu, 23 Nov 2023 at 14:20, Stephen Reay wrote:
>
> Out of the box, with no package manager or module loader or anything, you
> can do as little as call `spl_autoload_register` with no arguments, and
> have working class autoloading.
>
Sure, it's just about possible that you could paste that
Again, with so many absolutes. Static APIs aren't inherently bad;
rather, bad programmers write poor code. It seems like you're assuming
that PHP developers can't make decisions about what tools to use
independently and need explicit encouragement or endorsement from you.
Just because you are u
On Thu, Nov 23, 2023, at 1:43 AM, Robert Landers wrote:
> I'd venture to say that static classes have some unique benefits over
> plain functions. One, you can encapsulate state using private static
> variables. That simply isn't possible with regular functions (unless
> you use static variables i
> On 23 Nov 2023, at 19:42, Rowan Tommins wrote:
>
> On Thu, 23 Nov 2023 at 11:48, Stephen Reay wrote:
>
>>
>> Respectively, I disagree that it's "not a big problem" if your goal is to
>> encourage people to use regular functions over classes with static methods.
>>
>
>
> Just to be clea
On Thu, 23 Nov 2023 at 11:48, Stephen Reay wrote:
>
> Respectively, I disagree that it's "not a big problem" if your goal is to
> encourage people to use regular functions over classes with static methods.
>
Just to be clear, my answer was specifically addressing your point about
using Composer
> On 23 Nov 2023, at 17:21, Rowan Tommins wrote:
>
> On Thu, 23 Nov 2023 at 06:00, Stephen Reay wrote:
>
>> I'm disappointed to see yet again that there's this implied notion that
>> working with PHP in 2023 means "well surely you must be using composer",
>> which leads to "but composer..." s
On Thu, 23 Nov 2023 at 06:00, Stephen Reay wrote:
> I'm disappointed to see yet again that there's this implied notion that
> working with PHP in 2023 means "well surely you must be using composer",
> which leads to "but composer..." somehow being an accepted argument when
> it comes to missing/
On Thu, Nov 23, 2023 at 7:00 AM Stephen Reay wrote:
>
>
>
> > On 21 Nov 2023, at 06:48, Mike Schinkel wrote:
> >
> > Wow.
> >
>
> Hi,
>
> (This is not a direct reply to Mike, his just seems to be less shouty than
> other recent emails)
>
> I'm not *particularly* bothered by the results of this s
> On 21 Nov 2023, at 06:48, Mike Schinkel wrote:
>
> Wow.
>
Hi,
(This is not a direct reply to Mike, his just seems to be less shouty than
other recent emails)
I'm not *particularly* bothered by the results of this specific RFC either way
- a *similar enough* result is already possible
Am 20.11.2023 um 22:00 schrieb Lanre Waju :
> I will have to disagree with everything you said:
Side-note: This is IMHO not a good intro into a discussion ;-)
> I outlined what a static class would be: A class that cannot be instantiated
> in which all members are implicitly static. We already h
I wouldn't support this, personally. I'm not a voter but I mean just in
terms of gauging community feel about the proposal, without unnecessarily
repeating what's already been said I just want to register that I'm in
agreement with Larry and Kamil's comments.
What static classes would achieve goes
Wow.
This thread has gone from zero-to-toxic in no time flat, and with some
participants being borderline condescending. It is almost as if some folk are
still in kindergarten.
Maybe try a different approach, from both sides of this debate?
For the advocates, how about explaining the use-cas
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 maint
A class with a private constructor can still be instantiated. A class that
cannot be instantiated is pretty much useless. A static class would be just
a collection of functions. And I know that many developers write such
classes but it doesn't mean the language should encourage it. After all, if
so
Hi Lanre,
I like your idea and I was even thinking about proposing the same addition.
The thing that is missing in the description is how the static class should
handle magic methods. Should they be disabled for them?
One plus of static classes which exist in other languages are that we
wouldn't
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 h
On 20 November 2023 18:53:50 GMT, Deleu wrote:
>> It's probably not productive to just say "the people who voted last time
>> are wrong", but it was long enough ago that a new RFC on the topic wouldn't
>> break any rules.
>
>
>9 years is long enough to conclude that whatever happens, they weren't
On Mon, Nov 20, 2023, at 7:52 AM, Rowan Tommins wrote:
> On 19 November 2023 21:28:08 GMT, Lanre Waju 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
On Mon, Nov 20, 2023 at 1:43 PM Rowan Tommins
wrote:
> On 20 November 2023 08:35:15 GMT, Lanre Waju
> wrote:
>
> >1. I will personally implement this feature.
>
> That's good to hear, but the initial implementation is not the main cost
> of a new feature. Once we add something, it's very hard to
On 20 November 2023 08:35:15 GMT, Lanre Waju wrote:
>1. I will personally implement this feature.
That's good to hear, but the initial implementation is not the main cost of a
new feature. Once we add something, it's very hard to remove, and every future
change has to consider that feature and
Thank you for bringing those threads to my attention. I hadn't
encountered them before, but it appears to be the typical argument of "I
don't want this, so you shouldn't," along with "why do x when you can
just do y (notice how y is not x)."
1. I will personally implement this feature.
2. Thi
On 19 November 2023 21:28:08 GMT, Lanre Waju 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 stag
Hi again,
> Super on board with this
Sorry for top posting everyone, my bad, forgot to delete the rest of the
message :)
Regards,
Daniil Gentili
19 nov 2023 22:28:16 Lanre Waju :
> Hi, similar to the abstract and readonly modifiers to classes (similar in
> syntax only), I propose a class level "static" modifier that ensures:
>
> 1. The class cannot be instantiated and will throw an exception if attempted.
>
> 2. All methods and variable
Hi, similar to the abstract and readonly modifiers to classes (similar
in syntax only), I propose a class level "static" modifier that ensures:
1. The class cannot be instantiated and will throw an exception if
attempted.
2. All methods and variables in the class are implicitly static.
3. (o
27 matches
Mail list logo
