Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.217.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <33781781-2a63-78c1-68a1-9e19ad720d8d@gmail.com>
References: <CADqTB_gBFM_2yNDQemPs68Fab4Hbd8pGj38a3-HSQ+CRcnDyvA@mail.gmail.com>
 <CAF+90c9td1bt2zCbGfXdbGtFO-4qhJuJnkAEdsQDaH+wATDOmA@mail.gmail.com>
 <CAFMT4NpFBCJW1x3Yxz3FDx+6JGcdaGXZuBseEOaxXG0fnFHV0g@mail.gmail.com>
 <de01a2d6-f03a-834d-b211-213a6f4cca1e@gmail.com> <CAFMT4NppJ2+rO7Y9=kqSrYhwHGDQ_faSSPGmaSY6sZPRrOKCtQ@mail.gmail.com>
 <33781781-2a63-78c1-68a1-9e19ad720d8d@gmail.com>
Date: Mon, 8 Aug 2016 19:06:33 +0200
Message-ID: <CADqTB_hLCdgS4NibhfBiD0ZiNLtTM7rt6K_y62FKEqPdTpEV2A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d9cec32d73b0539927046
Subject: Re: [PHP-DEV] Function auto-loading
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a113d9cec32d73b0539927046
Content-Type: text/plain; charset=UTF-8

> If not, I don't see why we ever need to be able to autoload global
functions

Well, for consistency.

For one, if you're refactoring a global function to a namespaced one, this
inconsistency is going to be surprising.

In general, any inconsistency in a language is surprising. Why only
non-global functions can autoload, is going to require a longer
explanation. And that's bad.

If we support auto-loading only for namespaced functions, we're actively
favoring (potentially micro-) performance over consistency.

I use global functions. I know that's not popular, but it's a language
feature, and I use it - for things like test-frameworks and global view
helper-functions.

Single namespace spanning multiple files is also a case for me - that's not
a decision we should make; likely, a PSR and Composer auto-loading features
will drive those decisions. One should have the freedom to add a new
function to an existing namespace, and make that function auto-load, while
packaging that function as a separate optionally-installable package.

I can't see the introduction of arbitrary restrictions or limitations
leading to anything good, language-wise.

Unless there's a demonstrated, critical performance issue with auto-loading
of global functions, please, let's not cripple this feature with
inconsistencies from the get-go!


On Mon, Aug 8, 2016 at 6:46 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 08/08/2016 17:00, Levi Morrison wrote:
>
>>     I think saying "add a backslash in front of your function names to
>>     avoid them being slow" will just lead to lots of "lol wtf php sux".
>>
>>
>> They'll say the same when function and class autoloading don't work the
>> same way anyway. I think unifying their behavior over time is the best
>> solution forward. Yes, I'm talking about a BC break eventually, but the
>> suggestion to autoload only fully qualified function names could buy us
>> the time to make that BC break less severe.
>>
>
>
> Do you mean eventually changing the name resolution rules for functions to
> match those for classes? I wasn't around at the time it was discussed, and
> if we were adding them now would be tempted to say the leading \ should
> always be mandatory, just like it is for classes. But since we have what we
> have, I don't see that big an advantage to changing it.
>
> If not, I don't see why we ever need to be able to autoload global
> functions. "You want autoloading? Put it in a namespace." Like I say, that
> leaves the very small edge case of a single namespace spanning multiple
> files, and an autoloader implementation able to include one of them when a
> function is called from another.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a113d9cec32d73b0539927046--