> if you choose to use static methods instead of functions It's not a choice - functions are practically useless in a Composer context, and most everything PHP is now Composer packages.
> why do you need this special syntax for calling them then? Yeah, but the same logic applies to namespaces and classes: If you choose to use namespaces, why do you need aliases for classes? Strictly speaking, you don't - but it would be really ugly and inconvenient. Forcing you to qualify a namespace or the parent class of a function repeatedly is just noise, same as qualifying the namespace before every class or interface-reference. Agreed, it has no functional value, but neither does namespace-aliasing. Both have a considerable organizational benefit though: the ability to list all your class, interface and function imports at the top of a file. To me, that's valuable. Either way, guys, here's a preliminary RFC: https://wiki.php.net/rfc/use-static-function While trying to describe this, I have to say, this doesn't appear to be the slam-dunk it seemed to be - you can read the details on that page, but given the two alternative approaches described on this page, it seems this feature is likely to create just as many problems and WTF as the auto-loading RFC. I'm afraid one isn't much better or worse than the other in that sense really... Oh well :-/ On Thu, Jan 26, 2017 at 6:50 PM, Niklas Keller <m...@kelunik.com> wrote: > > The problem with stop-gap measures is they become entrenched, and the >> proper solution doesn't get implemented >> >> This would be my general point of view - unfortunately, functions are >> essentially useless at present, in a world with Composer, unless you're >> willing to preload all functions from all packages up-front. >> >> The only suggested solutions I've heard for the name resolution issue with >> function autoloading frankly are all horrible - much worse than this >> simple >> alternative. >> >> Add to that the fact that likely 90% of all functions in the wild (at >> least >> in Composer packages) are currently implemented as public static >> functions, >> and in my opinion, this is starting to sound less like a stop-gap and more >> like a simple solution to a problem we've been solving with a stop-gap >> for, >> oh, 10 years or so... > > > Again, if you choose to use static methods instead of functions, why do > you need this special syntax for calling them then? > > Regards, Niklas >
