Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123644
Precedence: bulk
MIME-Version: 1.0
References: <0cf69a14-f1b5-4077-9d91-d7b579485eec@scriptfusion.com>
 <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk> <1fc2f2d0-718f-45ec-8968-b66a1bde686e@scriptfusion.com>
 <c2472dca-a297-4f14-bf53-b0ab9a67d3c7@rwec.co.uk> <b6d67db7-6689-4a1c-ad62-32cc96a01392@scriptfusion.com>
 <CAPyeZ4NW3eoaaXonM8bTHmji0a=CpWx7m8B5h_X44-eFDfOQbw@mail.gmail.com>
 <D53A9527-EE4B-4DC2-9CA4-A982EF236917@rwec.co.uk> <adb0e17c-c5b8-4e82-9d78-b09355f8a5fa@app.fastmail.com>
 <CAB-BujYmFxyNQV0-PZYz72A8CUHnkVvuHwPBvtOiBO9vV7+uDQ@mail.gmail.com>
 <4e439377-5c20-40d7-bb99-5d0ac6c348e9@rwec.co.uk> <CAB-BujZF83_kZYsyWkMAjbowCfSmSaZ7OZebyOG_BNP1S+CGFw@mail.gmail.com>
 <c05a85a9-0b63-4a27-a72d-d3a2b5cf73ea@rwec.co.uk>
In-Reply-To: <c05a85a9-0b63-4a27-a72d-d3a2b5cf73ea@rwec.co.uk>
Date: Sun, 16 Jun 2024 22:30:08 +0200
Message-ID: <CAB-BujYes=rWN-Hxke=7SFv7MxuAy+zRQgYainShBgj8Xprwvw@mail.gmail.com>
Subject: Re: [PHP-DEV] Static class
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: andreas@dqxtech.net (Andreas Hennings)

On Sun, 16 Jun 2024 at 20:08, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 16/06/2024 18:54, Andreas Hennings wrote:
>
> Yes, the possibility for namespace part imports exists.
> Unfortunately these namespace imports usually need to be set up
> manually, whereas the regular class or function import has better
> automatic support from the IDE.
> Also, namespace fragments are often more generic than function names,
> so more likely to need a custom alias.
>
>
> That's why I said it was tricky: the language doesn't prevent IDEs sugges=
ting different imports; nor does it require you to name namespace fragments=
 differently from classes; but that's what happens in practice.

Right.
The main thing here would be to have a 90% deterministic way to
generate the imports.
We want to avoid meaningless choices a developer needs to make case by case=
.
I see some difficulties here, but there are probably ways to handle it.

> So to what extent do we build the language based on how it *can* be used,=
 and to what extent do we build it based on how it *is* used? What if that =
usage changes over time? What if we add more ways to do it, and those aren'=
t used either? I don't think there's an easy answer.

It depends how disruptive the change is.

E.g. symfony has a Yaml class with only class constants and static methods.
https://github.com/symfony/symfony/blob/35890e1ca999cb92d7b20c81bc07cdc2f17=
b7bb4/src/Symfony/Component/Yaml/Yaml.php
We can argue whether this is good or bad.
Or we can just slap a "static" modifier on the class, so that
developers know what to expect.
This does not prevent future refactoring, where these methods might be
converted to functions.

Btw, even with only the class constants left, this would still be an
all-static class.