Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "PHP internals" <internals@lists.php.net>, "Rasmus Schultz"
 <rasmus@mindplay.dk>
References: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
Date: Fri, 27 Jan 2017 17:52:22 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.yuqblkwuc9evq2@nikita-work-box>
In-Reply-To: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
User-Agent: Opera Mail/12.16 (Linux)
Subject: Re: [PHP-DEV] Not autoloading functions
From: inefedor@gmail.com ("Nikita Nefedov")

On Fri, 20 Jan 2017 10:04:44 +0300, Rasmus Schultz <rasmus@mindplay.dk>  
wrote:

> Just a quick thought.
>
> 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.
>
> 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.
>
> 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. 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?

Maybe we might think about modules this time?
Lots of languages use this approach and they seem to be pretty happy
with it.

Here's how it could look like, very abstractly. I don't really see
any big issues with the way how to implement it either.

https://gist.github.com/nikita2206/2e4ab1b314e840f93ed75a0b88266d35