Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97969
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDCh45me7W2uC1icsf_YOOGA9xrBRXCp-Bespv-_O+eddcA@mail.gmail.com>
References: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
 <CANUQDCh45me7W2uC1icsf_YOOGA9xrBRXCp-Bespv-_O+eddcA@mail.gmail.com>
Date: Thu, 26 Jan 2017 11:21:37 +0100
Message-ID: <CAF+90c_c9SD4rsoWKYmNQswk-g_qkLFET5VBtB3JGZtNq61Rbw@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Rasmus Schultz <rasmus@mindplay.dk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c1a03d6e939df0546fcb633
Subject: Re: [PHP-DEV] Not autoloading functions
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c1a03d6e939df0546fcb633
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 26, 2017 at 10:46 AM, Niklas Keller <me@kelunik.com> wrote:

> >
> > 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.
>

A question in conjunction with this: How would this call actually treat the
LSB and $this scope? Would it follow the normal rules for scoped method
calls, or prevent adoption of scopes? For example:

use A::__construct as ctor;
class A { public function __construct() {} }
class B extends A { public function __construct() { ctor(); } }

Would this become an alternative way of writing parent::__construct() in B?
Would it behave the same?

Nikita

--94eb2c1a03d6e939df0546fcb633--