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 <ras...@mindplay.dk>: > 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 the > 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 features > 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, which, > 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. The > 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 here, > 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 still > 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 believe > 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 need > language features and convenience that low-level languages can't deliver. > > We're not competing with C - and if we're competing with other scripting > languages on performance, we're already in a pretty good position, and > people who select a scripting language aren't basing their choice on raw > 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 scripting > language, and we will lose. > > > On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov <nikita....@gmail.com> wrote: > >> On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz <ras...@mindplay.dk> 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 the >>> difficulty, and a much more deeply rooted language problem exacerbating >>> 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 parent 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 other >> 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 namespaced 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 for >>> 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? >>> >> >> -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php