Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94949 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22742 invoked from network); 8 Aug 2016 20:15:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Aug 2016 20:15:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@mindplay.dk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@mindplay.dk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.217.169 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.217.169 mail-ua0-f169.google.com Received: from [209.85.217.169] ([209.85.217.169:36189] helo=mail-ua0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8B/48-33134-B78E8A75 for ; Mon, 08 Aug 2016 16:15:56 -0400 Received: by mail-ua0-f169.google.com with SMTP id 97so36279809uav.3 for ; Mon, 08 Aug 2016 13:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mindplay-dk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PmyZCA6JSbNvqDBYvDFPjrJBFa/3/Rj5KlndyzCJXzg=; b=ioaSA+aZis29EqsRxHgJAzvsFkrVbkNWBL+E82JAGRDCr38u8QQ3/tFrELS+uDSSdL 0d/uSyQ0obmpySDg6FDK6ptKDY/L929Z0nYP6t/mEu7hEn9HrDLWA6+YOebZjvXnZWQq XAjh43MB2MpGHK6YPr+sRGWlJxUXw4XE0m6/E+VVQFVJ4NkMhjjACZZ86RrKYmUmRnLe YKBw64mc4HKGNr8TGQ1lSmayXb85Z83PuYvwX3FTcmLp182Z6BCd/IfejFDJWrVqkmjN iONF7WYkgqiIw8KV5szpWrTBBn0XWKCHwJHLNvs8Na2krN0dfAWI7yngVQOraJlivkwy sujg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PmyZCA6JSbNvqDBYvDFPjrJBFa/3/Rj5KlndyzCJXzg=; b=F90PoR0klD2AR8pV3+saZYv9MfuQzK7hGo0TSfnMwCKvlqNCe8W4H8SL8l4TJmj77o aOk6yYaoJcji176MjpmfWHIh92srLgRfYn/QzsuxvW7Ypg1MOtco9JgwAilfFzPMy4wD qkx14UONGMsKIayUOjecIJ2J7gOaQO0hkRFTDJQCUvNqQBlCEv0eTl7B4kte6AECxivd 57J2mdjYBZ7V6/61YFYbQsh+PjWz0YHoCEr4txJ77fG/oZ3CGKBrf1om9y+cA5YTQ7x8 ++jOppWaumob3Sar5KXi7cYUFuJlE3qInCKe7v7IjAbzPVLLeMxnoZjg9O57BJ5wokS0 RsZg== X-Gm-Message-State: AEkoouvpZZZbRdr5h7dGHgP1PLm+TnJ2v+kBUMjQWXdel/yganSaUOFsnYPghP84uHsd4Y3uVldSb0BSZvKtPQ== X-Received: by 10.31.180.214 with SMTP id d205mr48077866vkf.140.1470687352774; Mon, 08 Aug 2016 13:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.153.195 with HTTP; Mon, 8 Aug 2016 13:15:51 -0700 (PDT) In-Reply-To: <1d89ec68-de5e-2670-aed1-f12872c073c3@gmail.com> References: <33781781-2a63-78c1-68a1-9e19ad720d8d@gmail.com> <1d89ec68-de5e-2670-aed1-f12872c073c3@gmail.com> Date: Mon, 8 Aug 2016 22:15:51 +0200 Message-ID: To: Rowan Collins Cc: internals Content-Type: multipart/alternative; boundary=001a1143900a3d0ab90539951555 Subject: Re: [PHP-DEV] Function auto-loading From: rasmus@mindplay.dk (Rasmus Schultz) --001a1143900a3d0ab90539951555 Content-Type: text/plain; charset=UTF-8 > 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 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, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --001a1143900a3d0ab90539951555--