Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123641
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> <c27d86a7-0de9-4164-beda-a2b26785ff14@app.fastmail.com>
In-Reply-To: <c27d86a7-0de9-4164-beda-a2b26785ff14@app.fastmail.com>
Date: Sun, 16 Jun 2024 19:37:15 +0200
Message-ID: <CAB-BujbQRdpTkLgmg-1dGVfJWaF=UvE6J9=_b+q_XSZgGQwOfA@mail.gmail.com>
Subject: Re: [PHP-DEV] Static class
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: andreas@dqxtech.net (Andreas Hennings)

On Sun, 16 Jun 2024 at 17:44, Larry Garfield <larry@garfieldtech.com> wrote:
>
> On Sun, Jun 16, 2024, at 10:24 AM, Andreas Hennings wrote:
> > Regarding function autoloading:
> >
> > A more interesting question to me is a convention where to put each function.
> > With classes, PSR-4 tells us exactly what one can expect to find in a
> > class file with a given name.
> > Perhaps a separate directory tree per package, with one file per sub-namespace?
> > Or just a package-wide functions.php?
> >
> >
> > Regarding static methods vs functions.
> >
> > From the older thread, I can see different levels of possible
> > objection to all-static classes:
> > 1. "Every static method should instead be either a non-static method,
> > or a regular procedural function."
> > 2. "Static methods are acceptable, but no class should exist that has
> > only static methods."
> > 3. "Static methods and all-static classes are acceptable, but no new
> > language feature is needed to specifically support all-static
> > classes."
> > 4. "A new language feature for all-static classes could be acceptable,
> > but it should be very minimal and declarative."
> >
> > I see myself somewhere between 3 and 4.
>
> For reference, I have documented my stance on statics here:
>
> https://peakd.com/hive-168588/@crell/cutting-through-the-static
>
> --Larry Garfield

Thanks, Larry!
This aligns more or less with your messages from the older thread.

> Make it a function.

This is fine, but:
If you would replace all of your functions with static methods in
all-static classes, your code would still be as testable as before.
The calls would look more verbose, perhaps more confusing.

Developers may find reasons to use static methods and possibly
all-static classes over functions:
- Conformity with an existing code base or ecosystem.
- Lack of a convention on where to put your namespaced methods, and
which namespace to use.
- Personal habit and familiarity.
- Convenience of moving code between static and non-static methods.
- The possibility of using private and protected static methods, and
static polymorphism (whether that is good or bad).
- Easy access to class constants.
- The static methods already exist.

Besides, the namespace lookup is generally less ambiguous for classes
than it is for methods.
A `str_starts_with()` call could reference a function
`Current\Name\Space\str_starts_with()`, or the global
`\str_starts_with()`.
A class always needs the explicit alias or a `\\` prefix.
At the same time, the top-level namespace is crowded with native
procedural functions, but not so much with native classes.
At first, this is just an inconvenience when reading the code.
But it can also lead to real bugs, if a function alias gets lost when
you resolve a merge conflict, and you don't notice it because there is
a top-level function with the same name.

So, the above would be reasons why developers might not go all the way
to namespaced procedural functions.

Then, the mere presence and habit of static functions will lead to
some cases of all-static classes.

Even if you only use static methods as named constructors (static
factory method), you can end up with an all-static class, as in my
example above:
- You start with private constructor + public static factory.
- You rename the part of the class that is instantiable, to better
distinguish different implementations, but you keep the static methods
in place for BC reasons.
  (this assumes that all dependent packages depend on the static
factory and on the interface, but not on the class directly).
- Now it would be nice to visibly mark the class non instantiable.

-- Andreas