Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_i9upaFv7MvwjedRL4QYV=b8Y6RCb6bYsawZVxtooxDeQ@mail.gmail.com>
References: <CADqTB_gBFM_2yNDQemPs68Fab4Hbd8pGj38a3-HSQ+CRcnDyvA@mail.gmail.com>
 <CAF+90c9td1bt2zCbGfXdbGtFO-4qhJuJnkAEdsQDaH+wATDOmA@mail.gmail.com> <CADqTB_i9upaFv7MvwjedRL4QYV=b8Y6RCb6bYsawZVxtooxDeQ@mail.gmail.com>
Date: Sun, 7 Aug 2016 16:32:37 -0300
Message-ID: <CAEsg9X1F_ZnysnnhRhtyedy+0F_fudXS+buU7indKeTKKbc1sw@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Function auto-loading
From: david.proweb@gmail.com (David Rodrigues)

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 <rasmus@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.ppv@gmail.com> wrote:
>
>> On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz <rasmus@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