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 <da...@php.net> wrote:
> On Mon, Aug 8, 2016 at 1:15 PM, Rasmus Schultz <ras...@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.coll...@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
>
>
>
>
>
