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.
The DX of static methods can be evaluated from two perspectives: The
calling side, and the declaration side.
On the calling code side, the class of a static method call is usually
visible in the place where the call is made,
For a function call, the namespace is usually only visible in the
imports list at the top of the file.
The class name that is part of a static method call hints at an object
type, whereas for a namespace fragment it may not be really clear what
it describes.
In a static factory call, like `Color::fromRgb($red, $green, $blue)`,
I would argue that having the class name as part of the call improves
DX.
On the declaration side, I like to have a static factory in the same
place as the class itself.
For other cases, it can vary whether having a class name as part of
the call improves DX or not.
On the declaration side, static methods do bring some additional
features, that is, to split out some parts into private and protected
methods.
This said, in many cases such classes could be converted to non-static
instantiable classes.
One benefit of static methods is how they can be part of incremental
refactoring.
- Split some functionality into a private method.
- Notice that this method does not depend on any object state, so we
make it static.
- Now that it is static, it could as well be public, if we clean up
the signature a bit. This way it can be reused and tested
independently.
- Now that it is public static, I rather want to move it out of the
class, into a utility class.
- Now that we have this standalone method, we could convert it to a
procedural function.
- OR, we may decide that the entire utility class should actually be
converted to a service, and the method to be not static.
Or:
- Move some functionality out of the constructor into a static factory.
- Let the static factory return different implementations based on the
parameters. E.g. Color::fromRbg() could return a GrayscaleColor object
or a RainbowColor object, depending on parameter values.
- Make `Color` an all-static class, because the specific
implementations have dedicated classes.
- Convert the static methods on `Color` into object methods on
`ColorFromRgbFactory`.
- OR, we discover static polymorphism (*) and "abstract protected
static function".
- Later we might decide that this was awkward, and convert everything
to object methods.
In both of these scenarios we have steps with an all-static class.
There are possibilities to move away from that.
But in some cases the all-static class is actually the sweet spot
where we want to stay.
Another case for an all-static class would be a class that only
contains class constants.
Yes, we can use `define(...)`, but sometimes we want class constants,
for similar arguments as above.
A third case is if the all-static class already exists, as part of a
legacy codebase, and we could not break it up even if we wanted to.
If we do end up with an all-static class, even as an intermediate
state, it can be useful to declare this in some way.
Developers should immediately see whether a class is instantiable or not.
A trait or a base class or an explicit private constructor can do the
job, but it won't be as universal as a language feature.
On the other hand:
From the older proposal by Lanre Waju:
All methods and variables in the class are implicitly static.
I would very much oppose this.
These implicit semantics would make it harder and error-prone to move
methods around from a regular class to an all-static class.
And it would be confusing to look at such a method, because typically
the class-level static declaration won't be visible when you look at
the method.
Also think of the noise in git commits caused by the conversion to an
all-static class.
(Btw the same problem applies to class-level readonly)
To me, the best version of a class-level "static" keyword would be as
a contract, and nothing more:
- The class cannot be instantiated.
- It cannot have a constructor or destructor, or any magic methods
that only apply to objects.
- It can only extend or be extended by other static classes.
(otherwise it should be declared "abstract" instead)
The same could be achieved with a native base class or trait with
private constructor, or even the same thing from php-fig.
This would be less clear and less powerful than a static keyword, but
also less invasive to the language.
(One such language feature could be a language-level base class or
trait, simply for the sake of unification)
From this thread:
In particular: static classes are implied final and they cannot inherit from any other class.
With the version of the static keyword as above, I would be against
this limitation.
Static polymorphism (*) is possible today, and it should be perfectly
fine to slap a "static" keyword on these classes, if they are
all-static.
This is not about whether or not we like or dislike static
polymorphism, but about not attaching unrelated meaning to a keyword.
An explicit "static final class" is more obvious than "static class"
with implicit final.
(*) The term "static polymorphism" is a bit questionable.
I obviously mean this:
class B {
static function f() {
return static::g();
}
protected static function g() {
return null;
}
}
class C extends B {
protected static function g() {
return 5;
}
}
assert(C::f() === 5);
I have used this in the past, and I am now questioning my choices in
some of these cases.
Still I would not consider it an anti-pattern.
--- Andreas