On Mon, 10 Apr 2023, G. P. B. wrote:
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
>
Hello,
This looks really interesting but it might be a good idea to add a
section for the definition of "pinning" and the scope of the pin. For
example, what is the output of this code, executed in this order (with
this new autoloading configured):
// Test.php
namespace Test {
function
On Thu, 13 Apr 2023 at 11:39, Jordi Boggiano wrote:
>
> On 2023-04-12 22:26, Rowan Tommins wrote:
> > I could just about live with that example changing so that the
> > fallback was cached, but I definitely don't think an explicit call
> > like \foo\strlen('x') should become an implicit alias for
On Mon, 10 Apr 2023 at 14:01, Ondřej Mirtes wrote:
>
> I don’t like the proposed function names:
I think we're going to leave thinking about changing the names until
the end of the discussion.
They don't really matter, and it probably would be better to avoid
clogging up the technical
On 2023-04-12 22:26, Rowan Tommins wrote:
I could just about live with that example changing so that the
fallback was cached, but I definitely don't think an explicit call
like \foo\strlen('x') should become an implicit alias for
\strlen('x'), which is apparently the current proposal.
I
On 12 April 2023 23:50:25 BST, Dan Ackroyd wrote:
>On Wed, 12 Apr 2023 at 17:32, Claude Pache wrote:
>>
>> The proposed modification of `function_exists()` will break existing code:
>
>Please can you submit a failing test to
>https://github.com/Girgias/php-src/tree/zend_autoloader that shows a
On 12 April 2023 23:50:25 BST, Dan Ackroyd wrote:
>On Wed, 12 Apr 2023 at 17:32, Claude Pache wrote:
>>
>> The proposed modification of `function_exists()` will break existing code:
>
>Please can you submit a failing test to
>https://github.com/Girgias/php-src/tree/zend_autoloader that shows a
On Wed, 12 Apr 2023 at 17:32, Claude Pache wrote:
>
> The proposed modification of `function_exists()` will break existing code:
Please can you submit a failing test to
https://github.com/Girgias/php-src/tree/zend_autoloader that shows a
BC break.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime
On 12/04/2023 17:31, Claude Pache wrote:
* keep the current semantics, that using a namespaced or qualified function
name, (including a function name given as string, which is implicitly fully
qualified), doesn’t fall back to the global scope, — even when a previous use
of the same function
> Le 10 avr. 2023 à 14:17, G. P. B. a écrit :
>
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
>
On Tue, 2023-04-11 at 11:57 +0100, G. P. B. wrote:
> No, array_map will trigger the autoloader (actually strlen() will
> trigger it once first) and the autoloader should then load the
> array_map function from the My namespace.
> However, if the autoloader does not correctly load the
On Tue, 11 Apr 2023 at 18:12, Hans Krentel via internals
wrote:
>
> So I'd love to see some commentary on a `function_alias()`
> if now function autoloading is considered to come in
I wouldn't be opposed to it, but it should be a separate RFC.
The implementation could be copied from
On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas
wrote:
>
> I would like to see a similar benchmark with function autoloading enabled.
> https://github.com/phpbenchmarks/
Can you point me to where one can tell the benchmark framework to use
a custom version of PHP?
> One of the big differences
On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas
wrote:
>
> To me, class autoloading is a performance feature. If we didn't care about
> performance, we would be fine with eagerly loading a bunch of classes as
> e.g. Java does.
I think (class) autoloading actually serves two purposes: as you say,
Hello George,
Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
> https://wiki.php.net/rfc/core-autoloading
>
> The existing SPL
On Monday 10 April 2023 14:17:04 (+02:00), G. P. B. wrote:
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism [...]
>
> The existing SPL autoloading functions would become aliases to the new
Core
> ones and will continue to work without any migrations
On 11 April 2023 13:21:08 BST, Mark Baker wrote:
>We have the special constants like \MyNamespace\MyClass::class. Would you
>envisage (or is there value in) equivalent constants like
>\MyNamespace\MyFunction::function?
This has come up before, but there are two things about ::class to bear in
On 11 April 2023 13:01:08 BST, Dan Ackroyd wrote:
>On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>>
>> Similarly, I think it should be possible to "unpin" a function
>> lookup with a later definition,
>
>Can you say what the technical justification for that is?
Perhaps "should" is too
On Tue, 11 Apr 2023 at 08:14, Michał Marcin Brzuchalski
wrote:
>
> Can we improve the RFC with a short description of issues on SPL autoload
> this RFC tries to address?
Sure, if you want to propose some clearer words than these:
"The spl_autoload_register() does not become an alias for
>
> We have the special constants like \MyNamespace\MyClass::class. Would
> you envisage (or is there value in) equivalent constants like
> \MyNamespace\MyFunction::function?
>
If anything, I would suggest renaming the existing constant to something
more meaningful. There is no point in adding
On 10/04/2023 14:17, G. P. B. wrote:
Dan and I would like to propose a new core autoloading mechanism that fixes
some minor design issues with the current class autoloading mechanism and
introduce a brand-new function autoloading mechanism:
https://wiki.php.net/rfc/core-autoloading
The existing
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>
> Similarly, I think it should be possible to "unpin" a function
> lookup with a later definition,
Can you say what the technical justification for that is?
There's reasons why (imo) it's probably wrong, but I don't currently
understand what
On 11 April 2023 12:16:18 BST, "G. P. B." wrote:
>
>However, we *already* do function pinning which can result in this
>behaviour via the function cache, see the following bug which defines a new
>function via eval():
>https://bugs.php.net/bug.php?id=64346
That's not the same thing - that's
> On Apr 10, 2023, at 07:17, G. P. B. wrote:
>
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
>
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
> > As a result of the pinning, function_exists() will return true for
> functions in namespaces that have been pinned to a global function.
>
> The lookup pinning seems like the right way to optimise the
> implementation, but I don't think it
On Mon, 10 Apr 2023 at 20:12, Anton Smirnov wrote:
> Hello George,
>
> I'm not sure I'm 100% correct but I think that this RFC still allows to
> call different functions for the same code, just not in the same run.
>
> Consider this pseudocode:
>
> //- funcs.php
>
> namespace My;
>
> function
On 10 April 2023 13:17:04 BST, "G. P. B." wrote:
>Hello Internals,
>
>Dan and I would like to propose a new core autoloading mechanism that fixes
>some minor design issues with the current class autoloading mechanism and
>introduce a brand-new function autoloading mechanism:
Hi George and Dan,
pon., 10 kwi 2023 o 14:17 G. P. B. napisał(a):
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading
Hello George,
I'm not sure I'm 100% correct but I think that this RFC still allows to
call different functions for the same code, just not in the same run.
Consider this pseudocode:
//- funcs.php
namespace My;
function myfunc(...) { ... }
function array_map(...) { ... }
//- code1.php
On Mon, Apr 10, 2023 at 10:01 AM Ondřej Mirtes wrote:
> I don’t like the proposed function names:
>
> autoload_register_class to me reads like “register this class for
> autoloading”. If I observe the intended meaning correctly, it should be
> called “register_class_autoloader”.
>
> Same for
On 10.04.2023 14:17, G. P. B. wrote:
Hello Internals,
Dan and I would like to propose a new core autoloading mechanism
I think it would make a lot of sense to have one function for all kind
of features, but the user should define which ones. For example:
Loader::register(callable
I don’t like the proposed function names:
autoload_register_class to me reads like “register this class for
autoloading”. If I observe the intended meaning correctly, it should be
called “register_class_autoloader”.
Same for autoload_register_function - better name would be
Hello Internals,
Dan and I would like to propose a new core autoloading mechanism that fixes
some minor design issues with the current class autoloading mechanism and
introduce a brand-new function autoloading mechanism:
https://wiki.php.net/rfc/core-autoloading
The existing SPL autoloading
33 matches
Mail list logo
