I can accept not supporting PSR directly but implementing the class
autoloader and stating "internals believes autoload in should exist, just
doesn't specify/support any particular implementation", this makes sense,
although I like PSR and don't really see others that make (as much) sense.
This me
> -Original Message-
> From: Sebastian Krebs [mailto:krebs@gmail.com]
> Sent: Friday, August 30, 2013 9:02 PM
> To: Stas Malyshev
> Cc: Sara Golemon; Anthony Ferrara; internals@lists.php.net
> Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
>
>
Hi!
> As far as complicated and fragile logic, as Nikita pointed out, you
> could put all of your functions inside of a "functions,php" in a
It's the same as making it Functions.php and a class. I don't see why we
should overhaul the autoloading in the engine and add so many complexity
just to av
Stas,
I see a number of places where hash lookup is replaced with
> zend_lookup_function, not with the macro. Moreover, zend_lookup_function
> for some reason copies and lowercases the argument, even though for hash
> lookup it should already be lowercased.
There was quite literally one place I
2013/8/30 Stas Malyshev
> Hi!
>
> > Well, static methods aren't the same as functions.
>
> The big difference being?
>
A function is stateless [1], a method isn't. A function operates only on
the passed parameters [1], the method operates on the parameters and the
context it inherits from the in
Hi!
> This seems to be the core of your argumentation in this thread: "Why
> don't you just use Foo::bar() instead of foo\bar()?"
>
> In which case, I wonder why we have functions at all. We could just use
> static methods instead after all. Maybe we should deprecate function
> support?
Maybe we
On Fri, Aug 30, 2013 at 7:10 PM, Stas Malyshev wrote:
> Hi!
>
> > Well, static methods aren't the same as functions.
>
> The big difference being?
>
This seems to be the core of your argumentation in this thread: "Why don't
you just use Foo::bar() instead of foo\bar()?"
In which case, I wonder w
On Aug 30, 2013, at 10:25 AM, Stas Malyshev wrote:
>
>> Furthermore, I think that's up to the community to decide how to do.
>> They mostly settled on a 1-class-to-1-file rule (which was not the case
>> prior to __autoload/spl_autoload). I am fully confident that they will
>> find a way that ma
Hi!
> A function is stateless [1], a method isn't. A function operates only on
> the passed parameters [1], the method operates on the parameters and the
> context it inherits from the instance (non-static), or class (static and
> non-static).
Static method is stateless in the same meaning as una
Hi!
> So nothing changes from present (at all) unless a function is not
> defined. Today, that's an error case. So the only performance change
> occurs if zend_hash_find (which is already there) returns FAILURE. THEN
> the logic which includes autoloading would run.
I see a number of places where
Hi!
> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.
PHP core already has autoload functionality. And I don't see how with
function autoloading (which has no natural mapping a
Hi!
> Well, static methods aren't the same as functions.
The big difference being?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> And to continue the discussion, I recall that we, as PHP contributors,
> disagreed to include a PSR-0 compatible autoloader into Core.
This has nothing to do with PSR-0 in core. This has everything to do
with the fact that class-per-file is an accepted pattern in PHP and many
other language
o: 'Julien Pauli'
Cc: 'internals@lists.php.net'
Subject: RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading
The problem I see with implementing this kind of functionality in Core is
that it relies heavily on convention; PSR-0 is specifically a configuration
of the core autoloader
Core is the place for it.
Bryan
-Original Message-
From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
Julien Pauli
Sent: Friday, August 30, 2013 3:50 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Just to
Stas,
On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev wrote:
> Hi!
>
> > I have created a new draft RFC implementing function and constant
> > autoloading in master:
> >
> > https://wiki.php.net/rfc/function_autoloading
> >
> > All feedback is welcome.
>
> I think it is an unnecessary complicati
Stas,
Moreover, since this replaces a simple hash lookup with additional two
> function calls (and also other operations included in those) everywhere
> in the engine, it will also have performance impact of one of the most
> frequently used operations in the engine - function calls - while
> prov
On Fri, Aug 30, 2013 at 11:46 AM, Johannes Schlüter
wrote:
> On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote:
>> Just to say : one benefit of this work would be to finally have autoload
>> functionnality (which is a Core feature IMO) included in Zend/ and no more
>> in an extension.
>
> What
On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote:
> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.
What is the benefit, except having more stuff in the engine? SPL is part
On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev wrote:
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes
On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara wrote:
> All,
>
> I have created a new draft RFC implementing function and constant
> autoloading in master:
>
> https://wiki.php.net/rfc/function_autoloading
>
> All feedback is welcome.
>
Just to say : one benefit of this work would be to finally
Am 30.08.2013 10:42, schrieb Julien Pauli:
> Perhaps is it also time to talk about this subject back and finally all
> agree on a default recommanded implentation of autoloading in PHP
> (internally supported) ?
The only autoloader implementation that makes sense to me is to use a
tool such as h
On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann wrote:
> Am 30.08.2013 03:23, schrieb Anthony Ferrara:
> > All feedback is welcome.
>
> Can we please get rid off the __autoload() function first before we
> consider adding new functionality?
>
Huge +1 to start deprecating this feature, then
Am 30.08.2013 03:23, schrieb Anthony Ferrara:
> All feedback is welcome.
Can we please get rid off the __autoload() function first before we
consider adding new functionality?
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
2013/8/30 Stas Malyshev
> Hi!
>
> > I have created a new draft RFC implementing function and constant
> > autoloading in master:
> >
> > https://wiki.php.net/rfc/function_autoloading
> >
> > All feedback is welcome.
>
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm
2013/8/30 Stas Malyshev
> Hi!
>
> > I disagree on the basis that namespaced functions/constants *do* fit the
> > same autoloading paradigm.
>
> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>
Well, static methods aren't the same
> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>
> Nothing, really... Just countering your specific premise.
> > Those function calls would only kick in if the function/constant wasn't
> > already defined, which will be the excep
Hi!
> I disagree on the basis that namespaced functions/constants *do* fit the
> same autoloading paradigm.
If they're already namespaced, what prevents one to put it in a class
and use good old PSR-compatible loading?
> Those function calls would only kick in if the function/constant wasn't
> a
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes and files (also recommended in the
> PSR). But for func
On Fri, Aug 30, 2013 at 12:58 PM, Stas Malyshev wrote:
> Hi!
>
>> It is
>
> Oops, clicked too soon. I wanted to conclude that I think it is too many
> complications in the engine for too little gain.
I agree with Stas here.
thanks
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://
Hi!
> It is
Oops, clicked too soon. I wanted to conclude that I think it is too many
complications in the engine for too little gain.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To u
Hi!
> I have created a new draft RFC implementing function and constant
> autoloading in master:
>
> https://wiki.php.net/rfc/function_autoloading
>
> All feedback is welcome.
I think it is an unnecessary complication. Classes fit autoloader
paradigm nicely, since the usual pattern is one class
All,
I have created a new draft RFC implementing function and constant
autoloading in master:
https://wiki.php.net/rfc/function_autoloading
All feedback is welcome.
Thanks
Anthony
33 matches
Mail list logo
