On Sun, 16 Jun 2024 at 17:44, Larry Garfield <la...@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
