Hi Larry, > On Jun 26, 2024, at 2:21 PM, Larry Garfield <la...@garfieldtech.com > <mailto:la...@garfieldtech.com>> 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>
