Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94952
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.217.179 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANaX5nct2kJZzAZZa_ZoXqeQ7Uea-jxvTXE=Yt5bAhfNmPwQ_w@mail.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> <CAFMT4NrHmn71UzqMNPTJe18M-9OjgsG2YDsdhhNJ-vfrsYu5yw@mail.gmail.com>
 <1d89ec68-de5e-2670-aed1-f12872c073c3@gmail.com> <CADqTB_gZJgtV2rVhzMd_ExpfXxW-w0wR8GVfNXJc6wFO6DOQmA@mail.gmail.com>
 <CANaX5nct2kJZzAZZa_ZoXqeQ7Uea-jxvTXE=Yt5bAhfNmPwQ_w@mail.gmail.com>
Date: Mon, 8 Aug 2016 22:44:29 +0200
Message-ID: <CADqTB_iwvWqVN6E3ycX7a8uVPmFgJuNUYACUQLnuD2z-ZN61gQ@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c1239e4a4745b0539957bb7
Subject: Re: [PHP-DEV] Function auto-loading
From: rasmus@mindplay.dk (Rasmus Schultz)

--94eb2c1239e4a4745b0539957bb7
Content-Type: text/plain; charset=UTF-8

Aren't stream wrappers already lazy-loaded?

e.g. stream_wrapper_register("random", RandomStreamWrapper::class) does not
afaik actually load anything.

Making stream wrappers directly registerable from e.g. "composer.json"
should be a near-trivial thing to implement, and would make them
effectively "autoload" - I imagine it's no more costly to pre-register the
protocol/class-name than e.g. pre-registering some other form of
auto-loader?


On Mon, Aug 8, 2016 at 10:23 PM, Davey Shafik <davey@php.net> wrote:

> On Mon, Aug 8, 2016 at 1:15 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
>
>> > Unfortunately, function name resolution has this quirk that class name
>> resolution doesn't, so something's got to give.
>>
>> I suppose.
>>
>> Well, then, how about making the feature work consistently for all
>> functions, by coupling it directly to the "use function" statement?
>>
>> In other words, the feature changes from being strictly about auto-loading
>> functions, to instead resolving an imported function - so it would be
>> triggered by the "use function" statement only, rather than by the use of
>> the function, and the resolved function pertains only to the scope of the
>> file.
>>
>> A function resolver would simply need to return a callable:
>>
>>     register_function_resolver(function ($name) {
>>         if ($name === "html") {
>>             return function ($str) {
>>                 return htmlspecialchars($str, ENT_HTML5);
>>             };
>>         }
>>
>>         if (substr($name, 0, 5) === "iter\\") {
>>             require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php";
>>             return $name;
>>         }
>>     });
>>
>> This mechanism is probably a lot easier to explain and understand - and
>> works equally for global or namespaced functions.
>>
>> It also lets you potentially do other weird shit, like overriding
>> var_dump() or hooking into certain function calls - which could enable you
>> to do a bunch of evil, but I'm not really big on complicating features
>> solely to keep users from doing harm; simpler language features tend to
>> allow you to do more stuff - good or evil.
>>
>> Likely the 99% use-case is simply for Composer to bootstrap your packages
>> for you, and this feature will permit you to do that.
>>
>> Okay, so it doesn't deal with namespaced constants, and maybe this is me
>> being opinionated, but who's going to import constants one by one?
>> Constants are usually better off grouped together in a class. Although I
>> don't suppose there's any reason this concept couldn't be expanded to work
>> for constants as well, for completeness at least - though I have doubts
>> that very many people would care...
>>
>> Anyways, just spitballing here :-)
>>
>>
>> On Mon, Aug 8, 2016 at 7:54 PM, Rowan Collins <rowan.collins@gmail.com>
>> wrote:
>>
>> > On 08/08/2016 18:03, Levi Morrison wrote:
>> >
>> >>     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.
>> >>
>> >>
>> >> I'm not sure why you would think a single namespace spanning multiple
>> >> files is a "very small edge case". I disagree. Here are some libraries
>> I
>> >> am aware of *off the top of my head* that use functions the same
>> >> namespace across multiple files:
>> >>
>> >>   * https://github.com/nikic/iter
>> >>   * https://github.com/lstrojny/functional-php
>> >>
>> >> As well as several of my personal projects. I do not think this is a
>> >> "very small edge case."
>> >>
>> >
>> > The "iter" example looks a long way from being autoloadable whatever we
>> > supported, but the example of one-function-per-file is definitely
>> relevant,
>> > so I stand corrected.
>> >
>> > After a bit of clicking, I even managed to find a line which would fail
>> to
>> > autoload under the proposed limitation:
>> >
>> > https://github.com/lstrojny/functional-php/blob/master/src/
>> > Functional/CompareObjectHashOn.php
>> >
>> > > return compare_on($comparison, $keyFunction);
>> >
>> > Although interestingly, at the top of the file there is a (technically
>> > unnecessary) "use function Functional\compose;" If there was a "use
>> > function Functional\compare_on;" as well, we'd be fine. (The function
>> name
>> > would then become qualified at compile time and trigger autoloading at
>> run
>> > time.)
>> >
>> >
>> > On 08/08/2016 18:06, Rasmus Schultz wrote:
>> > > 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!
>> >
>> > Sure, we could try to measure it, but remember that it's not just the
>> > engine code that has the extra cost, it will actually call a userland
>> > function every time you use a global function from inside a namespace if
>> > you don't add a leading "\". That userland function will probably do a
>> > bunch of string comparisons before deciding it's not interested, and may
>> > even try to stat a file or two. Those are really expensive operations,
>> so I
>> > think it's a long way from "micro-optimisation".
>> >
>> > Unfortunately, function name resolution has this quirk that class name
>> > resolution doesn't, so something's got to give.
>> >
>> >
>> > Regards,
>>
>
> Related to this, I'd like to see stream (and stream filter) autoloading.
> Essentially, if you fopen("random://foo")  it'll pass that string to an
> autoloader that will load and register the stream. It fails if at the end
> of the autoloader the stream isn't registered.
>
> Similar for filter and stream_filter_(pre|ap)pend() and loading stream
> filters.
>
> - Davey
>
>
>
>
>

--94eb2c1239e4a4745b0539957bb7--