That isn't a top post, look again.And I am not referring to packages,rather to the ability to define functions that aren't exposed to the users of a library. C doesn't have packages either yet this is possible in it. And marking it as internal is not the same thing at all. I am not going to argue about why a developer would use static methods and whether that is actually a sign that the developer doesn't understand OOP. But I do want to get this straight. Instead of actually hiding the function, your idea is to mark it with @internal (via PHPDoc)? To you, that solves the problem?
On Wed, Jun 26, 2024 at 1:46 PM Larry Garfield <la...@garfieldtech.com> wrote: > On Wed, Jun 26, 2024, at 6:05 PM, Lanre wrote: > > In JavaScript/Typescript, we can declare functions that are local to > > the current file by not exporting them. In C/C++ this is achieved by > > simply writing the function in the implementation file as opposed to > > the header. However, achieving a similar level of privacy in PHP > > requires using private static methods, or else you incur the overhead > > of creating an object for stateless functions. How do you propose > > handling such cases using namespaced functions? Can you think of any > > scenarios where hiding non-API functions might be necessary? I'm > > curious why you keep returning to namespaced functions when they don't > > fulfill the same role. > > > > Cheers, > > Lanre > > Please don't top-post. > > 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. > > 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." > > (ab)using static classes to emulate a pseudo-single-class-package is... > abusing static. > > 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. > > --Larry Garfield >
