On Sun, Aug 7, 2016 at 12:32 PM, David Rodrigues <david.pro...@gmail.com>
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 <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?
>
Perhaps the solution is to look at this as a forward-only feature, rather
than a backfill.
We only support autoloading for unambiguous names — 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
