Hi Larry,
> On Jun 26, 2024, at 2:21 PM, Larry Garfield <[email protected] <mailto:[email protected]>> wrote:
> PHP has no concept of packages at present, and thus no concept of package-level scope.
Not entirely true.
PHP has static classes, which are stand-ins for packages for as long as PHP does not inherently
support the concept of packages.
Arguing "that is abusing static" without offering an alternative is just Puritanistic
logic that ignores pragmatic real world needs.
> For marking a function as "package private", the same way you would for a
> package-private class today: @internal docblock. It's not ideal (the ideal would require
> packages), but it still communicates the intent, has worked for classes for 15 years at least, and
> signals "if you use this class/function/thing and it breaks later, that's on you,
> don't come crying to me."
Not only is @internal docblock not ideal, it sets up those internal properties to be
infected with usage as explained by Hyrum's Law[1]. Thus providing @internal
docblock as if it were a viable alternative to package private is essentially a non-serious
argument.
> PHP has no concept of packages at present, and thus no concept of package-level scope. A
> private static method is private not to a file or package, but to that class. (The class and file
> usually correlate in practice, but there's nothing in the language that mandates that.) I
> would love to have a concept of packages that we could use for scope, as most more recent languages
> have concluded that is the correct level at which to enforce visibility, NOT objects/classes.
> That's an entirely separate question, however.
If you really want people to stop "abusing static" then drive to address that entirely
separate question. Otherwise let others who are more pragmatic give the language features that they
need.
As a quick aside, I would argue that PHP should look at its biggest warts — which to me include
but are not limited to autoloading and namespaces — and deprecate them to be replaced with a
proper package system that leverages a symbol compiler instead of autoloading and that ejects the
god-awful choice of using the escape character for package name separation.
But I digress.
> To be blunt, 90% of uses of static methods in PHP are a sign the developer doesn't
> actually understand OOP and is just writing procedural code with more steps. The other 10% are
> either named constructors or cases that can now be replaced with attributes.
Speaking of best practices, there is a growing contingent of software developers who feel that OOP
should not be the future of software[2], e.g. that it was "a good idea at the time" but
now no longer.
My point here is that PHP should not let entrenched dogma drive language design but instead
pragmatically evolve as other languages are also evolving.
-Mike
[1] https://www.laws-of-software.com/laws/hyrum/
<https://www.laws-of-software.com/laws/hyrum/>
[2] https://news.ycombinator.com/item?id=8676872
<https://news.ycombinator.com/item?id=8676872>