On Sun, Jun 16, 2024, at 14:13, Rowan Tommins [IMSoP] wrote: > > > On 15 June 2024 18:39:20 BST, Valentin Udaltsov <udaltsov.valen...@gmail.com> > 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] >
Considering that I brought up an internal attribute not too long ago and it seems like “packaging” is a giant can of worms, I’d like to suggest we don’t even approach the topic. People on this list have very specific ideas of what that means and unless someone is going to finally try championing an rfc after 30 years, it shouldn’t even be a factor. — Rob
