Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125003
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 16 Aug 2024 17:38:35 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e1a9092a-8d18-4a27-ae73-58715e9bff19@app.fastmail.com>
In-Reply-To: 
 <CAL0xaBGbBRi3X68J39PYAsbUcN9+PqTGHJjnWZHEYkaipBwnkg@mail.gmail.com>
References: <34548342633f1d87b2fc77c643bd895a18f71b66.camel@ageofdream.com>
 <CAAwdEzBWN40q10Q5ua_ZME29dJSqs=BHB1LxJ62mN-vXWNw0xQ@mail.gmail.com>
 <79817594-f9a9-4f02-b48a-4bf39e4372e6@app.fastmail.com>
 <CAL0xaBGbBRi3X68J39PYAsbUcN9+PqTGHJjnWZHEYkaipBwnkg@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 16, 2024, at 1:31 PM, Arvids Godjuks wrote:

> Hello Larry,
> I feel obliged to remind about the 80/20 rule where the last 20% of=20
> progress ends up being 80% of all the work. And from the discussion=20
> it's already looking like there are some major questions and caveats=20
> and engine problems that are gonna rear their ugly heads. I'm more in=20
> favour starting with somewhat self-contained features and steadily wor=
k=20
> to expand on them as people put the effort into it. The same as was=20
> done with the type system. You can lay the proper foundation now, so=20
> it's not blocking future expansion, but I really do not think full=20
> embedded classes are gonna be a short endeavor - probably multiple=20
> years if not half a decade going by prior record on features of this=20
> size.
> --=20
>
> Arv=C4=ABds Godjuks
> +371 26 851 664
> arvids.godjuks@gmail.com
> Telegram: @psihius https://t.me/psihius

To go off on this tangent for a bit...

There's a difficult balancing act to be had here.  On the one hand, yes,=
 design small and grow as you get feedback makes sense.  On the other ha=
nd, if you don't think through the whole plan, those early steps could e=
nd up being blockers for expansion, not a benefit.  The most obvious exa=
mple, readonly was billed as a building block toward aviz.  It ended up =
making aviz harder, and it not passing the first time around.  It remain=
s to be seen if first-class callables end up getting in the way of full =
PFA in the future.  The piecemeal way in which anonymous functions have =
been added over time has led to a lot of rough edges, and made discussio=
ns about smoothing them over harder (eg, the auto-closure-long-callable =
RFC).

When those first steps are effectively set in stone forever, rather than=
 something you can adjust based on future feedback, "YAGNI" becomes an a=
ctively harmful approach to system design.

--Larry Garfield