Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97968
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.218 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
References: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
Date: Thu, 26 Jan 2017 10:46:44 +0100
Message-ID: <CANUQDCh45me7W2uC1icsf_YOOGA9xrBRXCp-Bespv-_O+eddcA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c09830e209d1b0546fc3ab8
Subject: Re: [PHP-DEV] Not autoloading functions
From: me@kelunik.com (Niklas Keller)

--94eb2c09830e209d1b0546fc3ab8
Content-Type: text/plain; charset=UTF-8

>
> Since the autoloading functions proposal is stalled, how about allowing for
> import of static functions instead?
>
>     use function Foo::bar;
>
>     bar(); // calls Foo::bar()
>
> There are two benefits to this approach:
>
> 1. There is immediate support for autoloading without any need for adoption
> or support in existing autoloaders.
>

It adds "support". Just use a static method then instead of inventing some
new alias system.


> 2. Pseudo-namespaces (abstract classes with stateless static functions) are
> already widely practiced in PHP - a lot of existing code would be supported
> as is.
>

That same code is already supported, no need for a language change here.


> The syntax when calling functions would be the same.
>
> If we had function autoloading, we would likely collect related functions
> in a file anyway - putting them in a class instead gives more less the same
> exact result.
>
> The only drawback I can see, is the inability to import a whole set of
> functions with one statement - but being explicit about external imports is
> widely considered best practice for classes and interfaces, so why not for
> functions.


Just import the class and you're fine, you have just imported a group of
functions.


> Yeah, it's a bit inconvenient, but at least we can move ahead
> and leverage existing code without changes or BC breaks. It's not all bad.
> It's better than nothing perhaps? :-)
>
> Thoughts?
>

I don't see any benefits here, just drawbacks. It adds yet another alias
system, function calls can now be function calls and static methods. What's
with the static scope? It gets lost here. Nothing shows there's a static
scope.

Strong -1 from me, sorry.

Regards, Niklas

--94eb2c09830e209d1b0546fc3ab8--