Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97896
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.173 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
In-Reply-To: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
Date: Fri, 20 Jan 2017 12:15:12 -0600
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <80CDA2D3-0DA2-4ED7-8023-4BE5EBF08779@gmail.com>
References: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Subject: Re: [PHP-DEV] Not autoloading functions
From: pmjones88@gmail.com (Paul Jones)


> On Jan 20, 2017, at 01:04, Rasmus Schultz <rasmus@mindplay.dk> wrote:
>=20
> Just a quick thought.
>=20
> Since the autoloading functions proposal is stalled, how about =
allowing for
> import of static functions instead?
>=20
>    use function Foo::bar;
>=20
>    bar(); // calls Foo::bar()
>=20
...
> 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? :-)

I find this intuitively appealing. It's an incremental change with =
tangible benefit in an imaginable timeframe, as vs a dramatic change in =
an unknowable timeframe.

However, I am not an internals expert, so I'll leave it to them to say =
how big a deal it would be to implement, and what the drawbacks are.


--=20
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php