Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94906 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8853 invoked from network); 7 Aug 2016 22:42:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Aug 2016 22:42:22 -0000 Authentication-Results: pb1.pair.com header.from=me@daveyshafik.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@daveyshafik.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.216.178 cause and error) X-PHP-List-Original-Sender: me@daveyshafik.com X-Host-Fingerprint: 209.85.216.178 mail-qt0-f178.google.com Received: from [209.85.216.178] ([209.85.216.178:36040] helo=mail-qt0-f178.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C9/B5-33134-C49B7A75 for ; Sun, 07 Aug 2016 18:42:21 -0400 Received: by mail-qt0-f178.google.com with SMTP id 52so196502174qtq.3 for ; Sun, 07 Aug 2016 15:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daveyshafik-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OOYZymOsbWpVBBGpF+aKUeLCEWR07Q9LEO4a0bTQHYA=; b=Nqj+YJNNrdGT2Sh0TVn5Tku/wnlycG1a+Tyf0Hdru+8ECG1go3tSviUwnl/AVVOgdR xXXgczS9nZ1xs1Iyeceklnv6fnF25jn6vwGXNPN/JN8TCOnGrwZvOuv3SgIavx1Y1B0m /SnvsJi8HKawWgyrUemci90NB1Da1FOcrVpeBVX7FrKXgsNLE41CmFMlIWgeNeTzBVNc SC9f5tYmVVRN0jxB9XSrL4/Aixkoz+s8DnrmrWCb0IU8BEakjSJ7VirxGT4cHcDGHMJl kh8wubhpaj85YXGW2xubO1VN9KiSIIO4NLup/RUsaAhT39M/riMJkaWY2Gt3x8Alji/r +Yag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OOYZymOsbWpVBBGpF+aKUeLCEWR07Q9LEO4a0bTQHYA=; b=Tf7p5IRgLZH9ULjhiOtDKRkGRtcMRuVuzI/ZoSVORrCoy2Ao46Hc72W9PTZM1yLyhZ Xp1upjZimh3r06uGomq/EwplVphhpTaslLKmPxAnkLaMncrP+JswkX4dbm0H1Y/OzTnO IuMzGiIltfbUQWDK9sTnxyvvzU01q7i5WKLtbqRB0DW2fegceBLB6sIVqi+i1vmfKIwU r9l3vB1c5CjWFslZpnqr9e71tot9MyINte0RnLgCJzt/qh6Fdcog+mq6g34ny+Ycyhxq +8R1AonFiRW+acPgoiZTkllcyO0FbYuu0X5pZPkVykYRCqoLiHAaZwRU8hjRwst6fQEU rJcQ== X-Gm-Message-State: AEkooutDgYsNyFNNaL1Ya8zvIFMzQGsupw1MUP+I4FNQibf1p2eLprNe56jlaE3uZAExp0Ie8adOMSDbaQGvc+A2 X-Received: by 10.200.49.129 with SMTP id h1mr24967135qte.103.1470609737307; Sun, 07 Aug 2016 15:42:17 -0700 (PDT) MIME-Version: 1.0 Sender: me@daveyshafik.com Received: by 10.237.55.138 with HTTP; Sun, 7 Aug 2016 15:42:16 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Aug 2016 15:42:16 -0700 X-Google-Sender-Auth: CoOfhqXN_1Nweh3-VGj4yI0f520 Message-ID: To: David Rodrigues Cc: Rasmus Schultz , Nikita Popov , PHP internals Content-Type: multipart/alternative; boundary=001a11c00386feee0d053983027b Subject: Re: [PHP-DEV] Function auto-loading From: davey@php.net (Davey Shafik) --001a11c00386feee0d053983027b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 7, 2016 at 12:32 PM, David Rodrigues wrote: > What should be the difference between a static method on a autoloaded > class? > > I guess that it could be done currently by use a static method. > In this case, I know exactly what method should be called, without > depends of an autoloader response. > > class String { > public static function strpos(...) { ... } > } > > In this case, I just need to call String::strpos(...) and done. > > I don't know if I'm missing something. > > 2016-08-07 9:07 GMT-03:00 Rasmus Schultz : > > Of course calling e.g. strpos() should not trigger the auto-loader > > repeatedly - can we cache the information that the auto-loader was > > attempted once during the current script execution? so that e.g. only t= he > > first call to strpos() triggers the auto-loader? > > > > I suppose it would still happen once for every namespace from which > > strpos() gets called, so maybe this optimization doesn't help much. > > > > I guess I'd say, benchmark it before making assumptions? Maybe the > > performance hit turns out to be negligible in practice. Hard to say. > > > > If a performance hit is inevitable, but marginal, I hope that we do not > let > > micro-benchmarks stand in the way of improving the language? > > > > With PHP 7, the language is in many ways almost twice as fast as it was > > before. I think it's fair to say, PHP has problems that are much bigger > > than performance - to most developers, performance is not a pain point > > anymore, if it was before PHP 7. > > > > I wish that I could change your focus from performance concerns to > actually > > focusing on the language itself. > > > > It seems that me that recent performance improvements have become > somewhat > > of a bottleneck that *prevents* new features and (worse) missing featur= es > > from completing and improving the language? > > > > The performance improvements could just as well be viewed as a factor > that > > creates new elbow room for new features and language improvements, whic= h, > > long term, likely have much more value to more developers than the > > performance of micro-benchmarks. > > > > At the end of the day, for like 9 our of 10 projects, PHP's core > > performance is not the bottleneck - things like database queries are. T= he > > cost of developing a project is also generally unrelated to core > > performance of the language. Hardware gets cheaper and faster every day= . > So > > who or what are we optimizing for? > > > > I don't mean to get too side-tracked from the original conversation her= e, > > but we should be designing for developers - not for machines. The > language > > is more than fast enough for what most developers need it for - and sti= ll > > nowhere near fast enough for, say, a JSON or XML parser, the kind of > things > > that require C or assembly level performance, and I really don't believ= e > > there's a substantial segment of use-cases that fall in between - for > most > > things, either you need performance that PHP can't get near, or you nee= d > > language features and convenience that low-level languages can't delive= r. > > > > We're not competing with C - and if we're competing with other scriptin= g > > languages on performance, we're already in a pretty good position, and > > people who select a scripting language aren't basing their choice on ra= w > > performance in the first place; if that was their concern, they'd pick = C. > > > > We should focus on competing with other scripting languages on features= , > > convenience, productivity, etc. - if our main concern is competing on > > low-level concerns like performance, those concerns will override the > > points that really matter to developers who choose a high-level scripti= ng > > language, and we will lose. > > > > > > On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov > wrote: > > > >> On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz > wrote: > >> > >>> I'd really like to see the function auto-loading proposal revived > and/or > >>> possibly simplified. > >>> > >>> The fact that functions are hard (in some cases impossible) to reach = by > >>> manually issuing require/include statements is, in my opinion, half t= he > >>> difficulty, and a much more deeply rooted language problem exacerbati= ng > >>> what should be trivial problems - e.g. install a Composer package, > import > >>> (use) and call the functions. > >>> > >>> Looks like a fair amount of work and discussion was done in 2013 on > this > >>> RFC: > >>> > >>> https://wiki.php.net/rfc/function_autoloading > >>> > >>> There was a (now stale) proof of concept implementation for the paren= t > RFC > >>> as well: > >>> > >>> https://wiki.php.net/rfc/function_autoloading2 > >>> > >>> What happened? > >>> > >>> It looks like the discussion stalled mostly over some concerns, > including > >>> reservations about performance, which were already disproved? > >>> > >>> One issue apparently was left unaddressed, that of whether a call to = an > >>> undefined function should generate an auto-load call to a namespaced = or > >>> global function - I think this would not be difficult to address: > trigger > >>> auto-loading of the namespaced function first, check if it was loaded= , > and > >>> if not, trigger auto-loading of the global function. > >> > >> > >> I feel like the problem here did not get across properly. Calling the > >> autoloader if a global function with the name exists will totally kill > >> performance. This means that every call to strpos() or any of the othe= r > >> functions in the PHP standard library will have to go through the > >> autoloader first, unless people use fully qualified names (which, > >> currently, they don't). This is completely out of the question. > >> > >> (The case where neither the namespaced nor the global function exists = is > >> not the problem. In that case calling the autoloader for the namespace= d > and > >> non-namespaced names in sequence is of course unproblematic.) > >> > >> Nikita > >> > >> > >>> Most likely a PSR > >>> along with Composer auto-loading features will favor a best practice = of > >>> shipping packages with namespaced functions only, so the performance > >>> implications of checking twice would be negligible in practice. > >>> > >>> Being basically unable to ship or consume purely functional packages > >>> leaves > >>> the functional side of the language largely an unused historical > artifact, > >>> which is sad. Keeping things functional and stateless often lead to > more > >>> predictable and obvious code - I think the absence of good support fo= r > >>> functions encourages a lot of over-engineering, e.g. developers > >>> automatically making everything a class, not as a design choice, for > the > >>> sole reason of being able to ship and reuse what should be simple > >>> functions. > >>> > >>> This RFC looks pretty solid to me. > >>> > >>> What will it take to get this rolling again? > Perhaps the solution is to look at this as a forward-only feature, rather than a backfill. We only support autoloading for unambiguous names =E2=80=94 if you want the autoloader to be called, either import the function with use, or use a [fully] qualified name. This should remove the ambiguities and performance concerns. - Davey --001a11c00386feee0d053983027b--