Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123624
Feedback-ID: id5114917:Fastmail
Date: Sun, 16 Jun 2024 09:33:07 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Static class
User-Agent: K-9 Mail for Android
In-Reply-To: <10F3E8CB-8569-4F22-9ACD-C4196CF5AB57@gmail.com>
References: <4a298266-d29c-44e8-abea-849fd3e23721@rwec.co.uk> <10F3E8CB-8569-4F22-9ACD-C4196CF5AB57@gmail.com>
Message-ID: <3595ABDE-3A86-42B5-91AB-98DA4639F08A@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 16 June 2024 03:00:39 BST, "Marco Aur=C3=A9lio Deleu" <deleugyn@gmail=
=2Ecom> wrote:
>If you appoint a different jury to try a 20 year old case, the decision o=
f the previous jury doesn't have any more weight than any other evidence on=
 its own=2E

You missed the point of the analogy=2E  The point is that that would only =
happen if you have some specific reason why the case needs to be reopened=
=2E=20

I'm not saying nobody is allowed to talk about this=2E I'm just saying, le=
t's start by looking at the old discussion, and discuss *specifically* what=
 might have changed, rather than waving our hands and saying "10 years is a=
 long time, so no opinion from that long ago can possibly be valid"=2E


>You may have core developers that voted no due to maintenance burden, but=
 if said maintainer is no longer active and new maintainers don't mind it, =
it's a moot argument because people changed=2E

The maintenance burden argument is actually a good example of *not* being =
about individuals=2E The argument is not "I don't want to maintain it", it'=
s "we shouldn't burden future maintainers with this"=2E


>You may have no votes casted because at the time PHP technical debt could=
n't cope with such a change, which maybe isn't relevant anymore because the=
 project evolved=2E

This, on the other hand, is a good example of one where we don't need to g=
uess=2E Look at the archives - were people concerned about the implementati=
on? If so, pointing out that the implementation would now be simpler would =
absolutely be a reason to bring it back to discussion=2E


>You may have community leaders voting no because they inherently disagree=
 with the concept but if they have moved on to other endeavors and current =
PHP community members like the concept, then society changes play a vital r=
ole in a different outcome=2E

Again, let's stop talking in the abstract, and look at this specific case=
=2E Can you point to changes in the usage of PHP that make this feature mor=
e likely to see wide use or acceptance? Do you think the community at large=
, who we are trying to represent here, is more or less likely to write a pu=
rely static class in 2024 than in 2014?


All I'm asking is that if we are going to revisit features we previously r=
ejected, we start with "here's why I think the arguments for and against th=
is feature have changed", rather than "I don't like the old result, I deman=
d a new vote"=2E

Regards,
Rowan Tommins
[IMSoP]