Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110918
MIME-Version: 1.0
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
 <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com> <CA+kxMuS4TwAz9gaZ0GRwsb1yw5=Y+GcarPqxJsb0QC7JY9CFkw@mail.gmail.com>
 <CALKiJKo1JWTOk7qpWMt2tpeziqft7_2hXfSAStNRRoSavsrs=g@mail.gmail.com> <f51d0b51-3ba6-43cb-95bb-e46f4a4ee7f7@www.fastmail.com>
In-Reply-To: <f51d0b51-3ba6-43cb-95bb-e46f4a4ee7f7@www.fastmail.com>
Date: Fri, 10 Jul 2020 15:05:26 +0100
Message-ID: <CA+kxMuR==L0PRZ1--SuHg+DPAK98Hc2dUeqivi6TPwsOU8DxFw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: Danack@basereality.com (Dan Ackroyd)

On Thu, 9 Jul 2020 at 18:04, Larry Garfield <larry@garfieldtech.com> wrote:
>
> I've no idea what the rules are around new version numbers
> of RFCs that haven't been up for a vote yet.

I pretty strongly recommend people against re-using documents. If it's
going to change significantly, using a new doc makes it easier to see
it's a different idea.

Alternatively summarising the changes might be more appropriate for
smaller changes.

Larry wrote:
> Which guidelines in particular bug you, and why?

Just to note, my problem isn't just with the details, but to pick out a few.

RFC text:
> Any namespaced code provided by PHP-SRC will use a sub-namespace of \PHP.
> That is, no PHP\Foo class may be defined,

That seems like something that will have reasonable exceptions to.

RFC text:
> Classes that are part of a disable-able extension
> Eg, \PHP\Sodium.

I don't believe extensions should necessarily be under a PHP
namespace. Instead that should be thought about case-by-case. Also,
extensions can move from being one that can be disabled to not being
disable-able.

RFC text:
> Upgrade path for existing classes
> That is, a rename introduced in PHP 8.2 is not eligible to have its
> old name removed until at least 10.0.

The reason for having aliases is mostly to allow easier upgrading. i.e.

i) User code runs on version x.y of PHP.
ii) User code runs on version x.(y+1) of PHP.
iii) The user changes any use of old names on x.(y+1).
iv) Old names can be remove in version x.(y+2)

Keeping aliases of old names around for longer than that isn't that
useful. But again, this should be thought about case-by-case.

Rowan Tommins wrote:
> This is pure whataboutery; the idea that reading a few
> naming conventions will be such a burden that somebody
> would have no time to review a feature is frankly ridiculous.

That's getting pretty close to just name-calling.

It's fine to think that there is a problem here, and that adopting
this RFC is an appropriate solution to that problem.

But I think that there isn't really a problem to solve here, and that
even if there is, solving it through an RFC is worse than just
ignoring the problem.

This difference in approach possibly comes from a difference in
philosophy. aka I think we're both making sensible arguments, but
based on different values of what is important, and so coming to
different conclusions.

I've recommended the book Systemantics before:
https://en.wikipedia.org/wiki/Systemantics It has lots of very useful
advice about the counter-intuitive results that emerge from decisions.
And it's from that approach to systems design that I'm basing my
thinking. One of the most simplest pieces of advice it gives is:
"First rule of systems design: do without out one if possible"

And one of the few pieces of advice that I give to people, that I'm
pretty sure is right is: "Accept you're going to be wrong - Make it
easier to correct mistakes." which was part of a whole talk I gave at
DPC*

I don't think this RFC provides much benefit now, and I don't think it
makes it easier to name things in the future. In fact it makes things
more difficult as any exceptions to the rules laid down in this RFC
now become "DEVIATIONS FROM OUR ALREADY DECIDED RULES!!1!" rather than
things that can be thought about as code, coding standards, and
people's personal preferences all evolve.

cheers
Dan
Ack

* Video: https://www.youtube.com/watch?v=TS9BNa1MDW0
Slides: http://docs.basereality.com/GoodOrBad_DPC/

Apologies for the quality of my voice which made the presentation
quality not as high as I had hoped. But it does lead to the 2nd piece
of advice I'm pretty sure is correct, which is "wear a seatbelt so you
don't damage your spine in a car crash" which might seem kind of
obvious advice in retrospect.