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
