Re: Static class

From: Date: Sun, 16 Jun 2024 12:13:52 +0000
Subject: Re: Static class
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message


On 15 June 2024 18:39:20 BST, Valentin Udaltsov <[email protected]> wrote:

>PHP does not have internal/private functions.
>Very often I use functions for really simple things like array_flatten
>(and register them via composer.json.autoload.files). But when the function
>requires decomposition to smaller ones, I switch to a static class with one
>public and some private static methods.

Namespace visibility or a native "internal" attribute is something that would be really
useful, I think, because it would be able to apply to whole classes as well as functions and
constants. It would also allow you to make the refactoring you mention without having to switch all
calls from Foo\bar() to Foo::bar()

In general, I think PHP should embrace the concept of "packages" much more - for larger
apps, there's a much greater scope for performance if OpCache could analyse multiple files at
once, and make assumptions about them. (A consideration which didn't apply when autoloading was
first introduced.)

With that in mind, instead of function autoloading, maybe we should think about an
"include_all" function, which accepted a wildcard/glob pattern. That would make it much
easier to use preloading, and move away from the "one class per file" layout, without
blessing an official tool like Composer, or a particular file layout.

Put together, those features would provide a powerful alternative to a lot of static classes - i.e.
those where no state or inheritance is required, just a grouping of code.

Regards,
Rowan Tommins
[IMSoP]


Thread (32 messages)

« previous php.internals (#123632) next »