Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123878
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <0b665744-b146-4276-9c55-e71717d974fd@app.fastmail.com>
In-Reply-To: 
 <CAM7F2--zTgD7ar7cXcX9xXf=5ZdLpz0tSVqUns1COonUKbZg9Q@mail.gmail.com>
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <ef0c3617-6757-45a1-a485-3f7c197fd599@app.fastmail.com>
 <4596aa73-cfd4-2292-7191-2839a5bab695@php.net>
 <CAM7F2--zTgD7ar7cXcX9xXf=5ZdLpz0tSVqUns1COonUKbZg9Q@mail.gmail.com>
Date: Wed, 26 Jun 2024 18:21:06 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Static class
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

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