Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97974
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.216.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANUQDChp+_iJxDh6vQi3eUc3C9M0EhMvJ7R3nGUoWf+kBG1rEA@mail.gmail.com>
References: <CADqTB_gfRW6orcm8QXYSTz7iq=1ofv0RVf36=JsLeS7_6-R3LA@mail.gmail.com>
 <24.D0.04124.AABB9885@pb1.pair.com> <CADqTB_i50Prp1g0QL9eQr0EO8poUWSUZqo1JvymJY+imwNE73Q@mail.gmail.com>
 <CANUQDChp+_iJxDh6vQi3eUc3C9M0EhMvJ7R3nGUoWf+kBG1rEA@mail.gmail.com>
Date: Thu, 26 Jan 2017 21:23:51 +0100
Message-ID: <CADqTB_ihhkukpLqFbb+uhgEwyHXxhTnR-FROewkA75AEKWE52Q@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113776f2a30be9054705205d
Subject: Re: [PHP-DEV] Re: Not autoloading functions
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a113776f2a30be9054705205d
Content-Type: text/plain; charset=UTF-8

> 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 <me@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
>

--001a113776f2a30be9054705205d--