Also I specifically said "we can declare functions that are local to the
current file by not exporting them.", Where did you get "package private"
from?

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
>

Reply via email to