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