Hi.
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
https://wiki.php.net/rfc/autofunc
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
Shouldn't the default type be T_CLASS|T_INTERFACE?
--
Ryan McCue
<http://ryanmccue.info/
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.Shouldn't the default type be T_CLASS|T_INTERFACE?
sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi,
2011/8/12 Ferenc Kovacs tyra3l@gmail.com
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.Shouldn't the default type be T_CLASS|T_INTERFACE?
sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?
From the users point of view I don't care. It's just another constant. Also
constants like
SPL_AUTOLOAD_CLASS
SPL_AUTOLOAD_FUNCTION
SPL_AUTOLOAD_CONSTANT
seems to be more obvious, because it reflects, that it belongs to
spl-autoload.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs
krebs.seb@googlemail.com wrote:
Hi,
2011/8/12 Ferenc Kovacs tyra3l@gmail.com
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.Shouldn't the default type be T_CLASS|T_INTERFACE?
sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?From the users point of view I don't care. It's just another constant. Also
constants likeSPL_AUTOLOAD_CLASS
SPL_AUTOLOAD_FUNCTION
SPL_AUTOLOAD_CONSTANTseems to be more obvious, because it reflects, that it belongs to
spl-autoload.
imo from the users point of view your suggested constant names are
much better, plus the T_* constants are provided by the tokenizer
extension, which AFAK could be disabled compilation time, and by
itself would be a bad idea to couple the two extension.
so +1 for your suggestion, I will update the RFC, and check out how
hard would be to create a patch.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Someone said that it won't be that easy, because functions are
searched within a namespace first and when they don't exist there,
then are called from global namespace.
Example:
<?php
namespace example;
echo substr('Test', 1, 1);
When calling function substr, Zend engine first tries to find function
example\substr. If such function doesn't exist, it tries just substr
which is found and called. Thanks to this lookup, we don't need to
escape all function calls with backslash prefix.
<?php
echo not_found(1);
When trying to autoload a function, which one should be auto loaded?
"example\not_found" or "not_found"?
Similar situation is with constants, because of BC a non-existing
constant must result in string with the same value as constant's name.
<?php
var_dump(MY_CONSTANT); // string(11) "MY_CONSTANT"
Some programmes rely on it (though it's not recommended) and calling
autoloader everytime would add significant load to such apps.
Jan Dolecek
juzna.cz@gmail.com
On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs
krebs.seb@googlemail.com wrote:Hi,
2011/8/12 Ferenc Kovacs tyra3l@gmail.com
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.Shouldn't the default type be T_CLASS|T_INTERFACE?
sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?From the users point of view I don't care. It's just another constant. Also
constants likeSPL_AUTOLOAD_CLASS
SPL_AUTOLOAD_FUNCTION
SPL_AUTOLOAD_CONSTANTseems to be more obvious, because it reflects, that it belongs to
spl-autoload.imo from the users point of view your suggested constant names are
much better, plus the T_* constants are provided by the tokenizer
extension, which AFAK could be disabled compilation time, and by
itself would be a bad idea to couple the two extension.so +1 for your suggestion, I will update the RFC, and check out how
hard would be to create a patch.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Am 12.08.2011 15:54, schrieb Jan Dolecek:
Someone said that it won't be that easy, because functions are
searched within a namespace first and when they don't exist there,
then are called from global namespace.Example:
<?php
namespace example;
echo substr('Test', 1, 1);When calling function substr, Zend engine first tries to find function
example\substr. If such function doesn't exist, it tries just substr
which is found and called. Thanks to this lookup, we don't need to
escape all function calls with backslash prefix.<?php
echo not_found(1);
When trying to autoload a function, which one should be auto loaded?
"example\not_found" or "not_found"?
Whats about "both"?
- Does <namespace><function> exists?
- Does <function> exists?
Till here everything is like usual
- Try to load <namespace><function>. Does <namespace><function> exists?
- Try to load <function>. Does <function> exists?
I make two additional assumptions:
- Like PSR-0 developers may get used to put their functions into
namespaces, thus custom functions usually get loaded in the first
"autoload-step" - I don't think anybody will use one-function-per-file, thus (lets say)
every function from one namespace is loaded at once.
Similar situation is with constants, because of BC a non-existing
constant must result in string with the same value as constant's name.
<?php
var_dump(MY_CONSTANT); // string(11) "MY_CONSTANT"Some programmes rely on it (though it's not recommended) and calling
autoloader everytime would add significant load to such apps.
In my opinion code, that relies on this should be treated as
"unstable" anyway. I don't think it's very useful to take care of bad
habits and also I don't think it's useful to accept/decline
features/enhancements, because there are convenience/fallback-features,
that were never recommended. Also it's even not a bc-break, because it
works. And however: There is a very easy workaround:
| define('MY_CONSTANT', 'MY_CONSTANT');
;)
Jan Dolecek
juzna.cz@gmail.comOn Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs
krebs.seb@googlemail.com wrote:Hi,
2011/8/12 Ferenc Kovacstyra3l@gmail.com
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.Shouldn't the default type be T_CLASS|T_INTERFACE?
sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?From the users point of view I don't care. It's just another constant. Also
constants likeSPL_AUTOLOAD_CLASS
SPL_AUTOLOAD_FUNCTION
SPL_AUTOLOAD_CONSTANTseems to be more obvious, because it reflects, that it belongs to
spl-autoload.imo from the users point of view your suggested constant names are
much better, plus the T_* constants are provided by the tokenizer
extension, which AFAK could be disabled compilation time, and by
itself would be a bad idea to couple the two extension.so +1 for your suggestion, I will update the RFC, and check out how
hard would be to create a patch.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Someone said that it won't be that easy, because functions are
searched within a namespace first and when they don't exist there,
then are called from global namespace.Example:
<?php
namespace example;
echo substr('Test', 1, 1);When calling function substr, Zend engine first tries to find function
example\substr. If such function doesn't exist, it tries just substr
which is found and called. Thanks to this lookup, we don't need to
escape all function calls with backslash prefix.<?php
echo not_found(1);
When trying to autoload a function, which one should be auto loaded?
"example\not_found" or "not_found"?
first example\not_found then \not_found if necessary.
Similar situation is with constants, because of BC a non-existing
constant must result in string with the same value as constant's name.
<?php
var_dump(MY_CONSTANT); // string(11) "MY_CONSTANT"Some programmes rely on it (though it's not recommended) and calling
autoloader everytime would add significant load to such apps.
the autoloader shouldn't affect this, if no const is found, then the
constname should be used.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi.
I really like to see this [1] and also I would like to see this in 5.4.
I cannot C, thus I would appreciate, if someone can provide a patch.
Additional I suggests to include constants (global/namespace, not the
class constants) into the RFC too.
[1] http://news.php.net/php.internals/54196
Am 06.08.2011 13:15, schrieb Ferenc Kovacs:
Hi.
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions? For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions? For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.
As Sebastian already mentioned, if all functions in a namespace are
grouped into one file, it would be simple to load that file using such
a concept.
Hi!
As Sebastian already mentioned, if all functions in a namespace are
grouped into one file, it would be simple to load that file using such
a concept.
Why wouldn't you just use a class?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
Am 14.08.2011 20:17, schrieb Stas Malyshev:
Hi!
As Sebastian already mentioned, if all functions in a namespace are
grouped into one file, it would be simple to load that file using such
a concept.Why wouldn't you just use a class?
Counterquestion: Why shouldn't I use functions? They exists, they are
official supported, they are neither marked as deprecated, nor ever
discussed to get removed at all. It feels a little bit weird to me, that
I need to explain, why one wants to use functions, that are part of the
language since ever. And (on the other hand) static methods are imo just
something different.
Regards,
Sebastian
Hi!
Counterquestion: Why shouldn't I use functions? They exists, they are
Because if you want to use functions of similar nature organized in a
package, that's what classes are used for. You want to do something that
goes contrary to how language is designed and then you want language to
change to fit your wrong usage. I don't see how it's good for the language.
discussed to get removed at all. It feels a little bit weird to me, that
I need to explain, why one wants to use functions, that are part of the
Please don't distort my words - nobody asked you why you need to use
functions in general. I asked why you don't use mechanisms for grouping
functions that exist in the language and work just fine with existing
semantics and instead want new semantics that has its own problems.
language since ever. And (on the other hand) static methods are imo just
something different.
How different?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
Am 14.08.2011 23:06, schrieb Stas Malyshev:
Hi!
Counterquestion: Why shouldn't I use functions? They exists, they are
Because if you want to use functions of similar nature organized in a
package, that's what classes are used for.
When I must use classes are for packaging functions (that aren't
functions anymore, when I make methods out of them), what are namespaces
for? I'm just curious ^^
You want to do something that
goes contrary to how language is designed and then you want language to
change to fit your wrong usage. I don't see how it's good for the language.
I just want to use functions. Whats wrong with that? Really: Thats all.
discussed to get removed at all. It feels a little bit weird to me, that
I need to explain, why one wants to use functions, that are part of thePlease don't distort my words - nobody asked you why you need to use
functions in general. I asked why you don't use mechanisms for grouping
functions that exist in the language and work just fine with existing
semantics and instead want new semantics that has its own problems.
Its not (only) about grouping functions, its about using custom
functions at all. Grouping things is always a good idea and with
namespaces (not classes) it is already possible in a very clean and easy
way. There is no need to misuse OOP for that. As far as I can see there
is absolutely nothing new here. That functions/constants should be
covered by autoloading is the only thing I would like to see in one
future release.
language since ever. And (on the other hand) static methods are imo just
something different.How different?
Static methods are (static) methods and functions are functions. Classes
can get extended [1] and have a state and such. In short: Both methods
and functions come from two different paradigms (OOP and
procedural/functional). Just saying "static methods are just grouped
functions" is a little bit to less and will always feel like a hack to
me. PHP calls itself "multiparadigm", but the prodecural part feels very
neglected over the time.
Regards,
Sebastian
[1] Yes, I know, I can mark a class as "final", but this keyword is imo
the most useless keyword ever ;)
Hi!
I just want to use functions. Whats wrong with that? Really: Thats all.
Nothing at all. But changing semantics of the language because somebody
doesn't want to use existing semantics doesn't look like a good idea to
me. PHP has means to do what you want to do. If you don't want to use
them - well, that's your decision.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
Am 15.08.2011 02:37, schrieb Stas Malyshev:
Hi!
I just want to use functions. Whats wrong with that? Really: Thats all.
Nothing at all. But changing semantics of the language because somebody
doesn't want to use existing semantics doesn't look like a good idea to
me. PHP has means to do what you want to do. If you don't want to use
them - well, that's your decision.
Now I'm getting a little bit confused: About which new/changing
semantics you are talking about? I want to use custom functions, that
exists, since the language itself exists, but I want to get rid of
unnecessary [include|require]_once()
-calls.
I really don't see any new semantics here.
Regards,
Sebastian
Hi!
Now I'm getting a little bit confused: About which new/changing
semantics you are talking about? I want to use custom functions, that
exists, since the language itself exists, but I want to get rid of
unnecessary[include|require]_once()
-calls.
You want to change how autoloader works. This would also be a problem
with global function callback for namespaces
(http://www.php.net/manual/en/language.namespaces.fallback.php) since
each call to, say, strlen would produce an autoloader call.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
2011/8/15 Stas Malyshev smalyshev@sugarcrm.com
Hi!
Now I'm getting a little bit confused: About which new/changing
semantics you are talking about? I want to use custom functions, that
exists, since the language itself exists, but I want to get rid of
unnecessary[include|require]_once()
-**calls.You want to change how autoloader works. This would also be a problem with
global function callback for namespaces (http://www.php.net/manual/en/**
language.namespaces.fallback.**phphttp://www.php.net/manual/en/language.namespaces.fallback.php)
since each call to, say, strlen would produce an autoloader call.
I already made an suggestion [1], that bypass this.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Regards,
Sebastian
Hi!
I already made an suggestion [1], that bypass this.
That suggestion means you can not autoload namespaced function that
overrides global function. Major WTF. Also leads to two autoload calls
(one most probably resulting in exhaustive include path search) when
autoloading a non-namespaced function. Pretty bad idea IMO.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I already made an suggestion [1], that bypass this.
That suggestion means you can not autoload namespaced function that
overrides global function. Major WTF. Also leads to two autoload calls (one
most probably resulting in exhaustive include path search) when autoloading
a non-namespaced function. Pretty bad idea IMO.
It seems to me that the goal is a Python-esque approach to functions.
A module (or namespace) has a number of functions, classes, etc. Once
that namespace is loaded, everything is then accessible. This is
similar to wrapping a number of functions within a class. The main
difference is that using the namespace would allow functions to be
called without a prefix.
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
2011/8/15 Stas Malyshev smalyshev@sugarcrm.com
Hi!
I already made an suggestion [1], that bypass this.
That suggestion means you can not autoload namespaced function that
overrides global function. Major WTF.
Imo overriding built-in functions is a WTF... Confusing others by changing
the behaviour of well-known functions just sounds scary.
However, when you really want to do this, than you can load your functions
like before
Also leads to two autoload calls (one most probably resulting in exhaustive
include path search) when autoloading a non-namespaced function. Pretty bad
idea IMO.
Please read my other mail completely:
- Developers will get used to namespace everything of their stuff to avoid
name conflicts (exactly like it is for classes already) - Usually more than one function is loaded at once, thus you will probably
safe other autoloader-calls later on.
This means, there will be two calls to the autoloader only when the
function does not exists at all. In this case you have other problems than
the two calls.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Imo overriding built-in functions is a WTF... Confusing others by changing
the behaviour of well-known functions just sounds scary.
So you want also to change namespace semantics...
However, when you really want to do this, than you can load your functions
like before
So to make your scheme work properly, you need to preload... As I said,
not a very good idea. I'm definitely against it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Mon, Aug 15, 2011 at 9:15 AM, Sebastian Krebs
krebs.seb@googlemail.com wrote:
2011/8/15 Stas Malyshev smalyshev@sugarcrm.com
Hi!
I already made an suggestion [1], that bypass this.
That suggestion means you can not autoload namespaced function that
overrides global function. Major WTF.Imo overriding built-in functions is a WTF... Confusing others by changing
the behaviour of well-known functions just sounds scary.
Stas was referring to the fact that namespaces already provides this
kind of monkey-patching, of course this won't work language constructs
(which is a big wtf for most users in it's own way).
However, when you really want to do this, than you can load your functions
like beforeAlso leads to two autoload calls (one most probably resulting in exhaustive
include path search) when autoloading a non-namespaced function. Pretty bad
idea IMO.
my idea was something similar what Sebastian suggested, to call the
autoloader twice, but now I think that the best way would be to:
1, we check that the function exists in the current namespace
2, call the autoload callbacks with the absolute name (foo\bar\baz).
3, we check that the function exists in the global namespace
this would of course mean that for every occasion when you forgot to
put the \ for your global function calls your autoloader gets called,
but that's a bad practice, and I really hope that the namespace
fallback will be deprecated/removed in future versions.
it had a nice promise: you can use namespaces without rewriting your
whole application, but with the current implementation, thats simply
not true_
- you have to put your namespace declaration into every file, included
files won't inherit that. - you can't use the classname type constructors in namespaced code.
so this is a valid concern, but I still think that the people who
would use this feature could still live with either of the proposed
solutions.
I know that the bad decisions in the past won't count in this
argument, but the current "namespace resolution falls back to the
global namespace" is the one to blame for this shortcoming.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
I know that the bad decisions in the past won't count in this
argument, but the current "namespace resolution falls back to the
global namespace" is the one to blame for this shortcoming.
It's not a shortcoming, it was designed that way, and for very serious
reasons. If you want to know the reasons, there were discussed
extensively when namespaces were discussed. Please re-read that
discussion. And all things you propose now were already discussed back
then too. If you hope people would write \strlen instead of strlen, this
discussion is pointless because it won't happen.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I know that the bad decisions in the past won't count in this
argument, but the current "namespace resolution falls back to the
global namespace" is the one to blame for this shortcoming.It's not a shortcoming, it was designed that way, and for very serious
reasons.
it depends on what do you mean by designed, it was brought up after
the namespace support was implemented, and the namespace separator
debate closed AFAIK.
If you want to know the reasons, there were discussed extensively
when namespaces were discussed. Please re-read that discussion. And all
things you propose now were already discussed back then too. If you hope
people would write \strlen instead of strlen, this discussion is pointless
because it won't happen.
if somebody don't have the links, here they are:
internals@lists.php.net/msg39829.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg39829.html
internals@lists.php.net/msg39577.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg39577.html
https://wiki.php.net/rfc/namespaceresolution
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hello Stas,
Hi!
It's not a shortcoming, it was designed that way, and for very serious
reasons. If you want to know the reasons, there were discussed extensively
when namespaces were discussed. Please re-read that discussion. And all
things you propose now were already discussed back then too. If you hope
people would write \strlen instead of strlen, this discussion is pointless
because it won't happen.
I see your viewpoint from a architectural/design perspective and they
are valid, but I think the impact and design could be lightened with
some simple rules of precedence.
I think it would be fair to say, autoloader will not be called on a
function like strpos, or any builtin compiled extension. Only once
those are cycled through will autoloader for functions be called. At
this point the performance penalty doesn't exist, because at this
point the program execution would have halted with a fatal error
anyways.
-Chris
This member of the peanut gallery would like to point out the following
danger. Consider the following function collection for namespace A.
namespace A;
function strpos()
{}
function myfunc() {}
Now if I understand the RFC correctly there's an unintuitive problem as
follows - if myfunc is called first, strpos gets redefined for that
namespace and functions as the author might expect for the namespace. If
strpos gets called first then it will behave as it does in the global
namespace, which may or may not be desirable. In any event, from where I
stand here in userland, this is potentially confusing. I'm an amateur of
the 1st degree, but my gut tells me that the behavior state of any given
function should NOT be determined by whether or not a different function was
invoked before it.
On Mon, Aug 15, 2011 at 5:49 PM, Chris Stockton
chrisstocktonaz@gmail.comwrote:
Hello Stas,
On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
It's not a shortcoming, it was designed that way, and for very serious
reasons. If you want to know the reasons, there were discussed
extensively
when namespaces were discussed. Please re-read that discussion. And all
things you propose now were already discussed back then too. If you hope
people would write \strlen instead of strlen, this discussion is
pointless
because it won't happen.I see your viewpoint from a architectural/design perspective and they
are valid, but I think the impact and design could be lightened with
some simple rules of precedence.I think it would be fair to say, autoloader will not be called on a
function like strpos, or any builtin compiled extension. Only once
those are cycled through will autoloader for functions be called. At
this point the performance penalty doesn't exist, because at this
point the program execution would have halted with a fatal error
anyways.-Chris
--001636833a84f3029304aab9fd15
Content-Type: text/plain; charset=ISO-8859-1This member of the peanut gallery would like to point out the following
danger. Consider the following function collection for namespace A.namespace A;
functionstrpos()
{}
function myfunc() {}Now if I understand the RFC correctly there's an unintuitive problem as
follows - if myfunc is called first, strpos gets redefined for that
namespace and functions as the author might expect for the namespace. If
strpos gets called first then it will behave as it does in the global
namespace, which may or may not be desirable. In any event, from where I
stand here in userland, this is potentially confusing. I'm an amateur of
the 1st degree, but my gut tells me that the behavior state of any given
function should NOT be determined by whether or not a different function was
invoked before it.
There's nothing saying you can't have the exact same situation right now
with classes and autoloading, too.
Example:
namespace A;
class ReflectionClass
{ /* ... */ }
class MyClass
{ /* ... */ }
What if you have an autoloader that, on encountering A\MyClass then
loads that file? You've now redefined ReflectionClass for the A
namespace.
The main difference, of course, is that if ReflectionClass is not
explicitly imported, PHP will barf and tell you it doesn't know about
A\ReflectionClass.
While I understand your objections, I think that after the functionality
exists, there can be discussions about best practices -- e.g., putting
one function per file when autoloading, or documenting when all
functions for a given namespace will be in a single file. It's really a
matter of the project educating its users -- I don't think it should be
a blocker for implementing it at the language level, though.
On Mon, Aug 15, 2011 at 5:49 PM, Chris Stockton
chrisstocktonaz@gmail.comwrote:Hello Stas,
On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
It's not a shortcoming, it was designed that way, and for very serious
reasons. If you want to know the reasons, there were discussed
extensively
when namespaces were discussed. Please re-read that discussion. And all
things you propose now were already discussed back then too. If you hope
people would write \strlen instead of strlen, this discussion is
pointless
because it won't happen.I see your viewpoint from a architectural/design perspective and they
are valid, but I think the impact and design could be lightened with
some simple rules of precedence.I think it would be fair to say, autoloader will not be called on a
function like strpos, or any builtin compiled extension. Only once
those are cycled through will autoloader for functions be called. At
this point the performance penalty doesn't exist, because at this
point the program execution would have halted with a fatal error
anyways.-Chris
--
--001636833a84f3029304aab9fd15--
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Hi!
There's nothing saying you can't have the exact same situation right now
with classes and autoloading, too.
Well, there is something - the "file per class" custom which is followed
quite widely.
And also classes don't have fallbacks, while the functions do.
While I understand your objections, I think that after the functionality
exists, there can be discussions about best practices -- e.g., putting
one function per file when autoloading, or documenting when all
I'm not sure anybody would really do function-per-file - it's too tedious.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, August 17, 2011 7:37 PM
To: Matthew Weier O'Phinney
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*Hi!
There's nothing saying you can't have the exact same situation right now
with classes and autoloading, too.Well, there is something - the "file per class" custom which is followed
quite widely.And also classes don't have fallbacks, while the functions do.
While I understand your objections, I think that after the functionality
exists, there can be discussions about best practices -- e.g., putting
one function per file when autoloading, or documenting when allI'm not sure anybody would really do function-per-file - it's too tedious.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Tedious, and slow because the overhead for each file loaded can easily be in the 2-5ms range. Nobody is going to have a function per file, but they are still likely to use function autoloading in other ways. A likely case for this would be to autoload a group of functions that all share the same prefix. Another case might be to autoload a set of functions that are related to something else (for example, usability of singleton classes would benefit greatly from having a function of the same name as the class, or classes may want to provide a factory function of the same name.)
John Crenshaw
Priacta, Inc.
P.S. Before someone flames me about the evilness of singletons, yes, I know; but, occasionally they still have a place. There is usually only one session, there is only one app, there is usually only one database, logging is usually configured globally, etc.
I'm not so sure about that. For example, class PDO is PHP core. Suppose I
create A\PDO. When PHP is asked for A\PDO and fails to find it then it will
die. Correct me if I'm wrong but I think it does NOT go looking for \PDO.
Another bugbear is classes will most likely be 1 class = 1 file. Functions
will probably end up being all functions of the namespace, 1 file.
Perhaps there's another way to do this that isn't as fraught with confusion,
though I have no idea of what the engine details are or if it's possible.
Suppose you have an autoloading function that triggers the first time a
namespace is mentioned to pull up definitions for that namespace. So when
the engine sees "namespace A;" declared for the first time It sees if any
autoloaders are present for namespace A. If yes, it fires them loading the
library files for the namespace.
Another, similar, approach is one I've been using in my own framework. When
the class autoloader first sees a namespace, it checks the filesystem for a
namespace definition file that holds functions and constants of the
namespace and then loads it (require_once) along with the requested class.
Since my framework is object oriented calls to a function that doesn't
belong to a specific class will not be emitted outside of a class method and
this has been sufficient to handle the problem for which this RFC is
supposed to solve within PHP 5.3. Just a thought.
On Wed, Aug 17, 2011 at 5:44 PM, Matthew Weier O'Phinney <
weierophinney@php.net> wrote:
There's nothing saying you can't have the exact same situation right now
with classes and autoloading, too.Example:
namespace A;
class ReflectionClass
{ /* ... */ }class MyClass
{ /* ... */ }What if you have an autoloader that, on encountering A\MyClass then
loads that file? You've now redefined ReflectionClass for the A
namespace.The main difference, of course, is that if ReflectionClass is not
explicitly imported, PHP will barf and tell you it doesn't know about
A\ReflectionClass.While I understand your objections, I think that after the functionality
exists, there can be discussions about best practices -- e.g., putting
one function per file when autoloading, or documenting when all
functions for a given namespace will be in a single file. It's really a
matter of the project educating its users -- I don't think it should be
a blocker for implementing it at the language level, though.--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Hi,
Am 14.08.2011 15:55, schrieb Derick Rethans:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions?
For the same reasons, why class-autoloading is useful: Loading when
needed and avoiding unnecessary repetitive include-statements.
For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.
Like classes there may be also a function-to-filename-mapping,
especially now, since namespaces exists. It is very easy to extend the
PSR-0 standard (lets say: PSR-0.1 ;)) so functions and constants are
covered by it too:
- Constants and functions are in a file named after the namespace
myNamespace\foo\bar => MyNamespace/foo/bar.php
When class-autoloading were introduced there were no ^real^
class-to-file-mapping too. You had to define it yourself the time, when
you wrote your __autoload()
-function. It's nearly the same with
functions/constants now, except that we are away from a single function
and that there are already ideas, that may cover such mappings already.
Or in my words: I don't see any reason, why
function-/constant-autoloading does not exists ;)
cheers,
Derick
Regards,
Sebastian
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions? For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.
Namespaces support the following code types:
- Constants
- Functions
- Classes and Interfaces
Currently, autoloading in PHP allows us to dynamically identify and load
only classes and interfaces. However, not all code is written using OOP.
If a developer doesn't want to dive into include/require(_once) hell in
order to use their namespaced functions and/or constants, they have no
real options.
As an example, let's say I've created a procedural CMS or blog of some
sort. In there, I have a file like this:
<?php
namespace MyProjectName\Posts;
$entries = getEntries(date('Y'));
foreach ($entries as $entry) {
displayEntrySummary($entry);
}
Next, assume the "getEntries" and "displayEntriesSummary" functions are
also in the namespace "MyProjectName\Posts". How does my code load those
functions?
Traditionally, we've used:
include_once 'MyProjectName/Posts/functions.php';
or
include_once __DIR__ . '/functions.php';
in our files. But why should we have to do that? Why are functions --
which make up the bulk of PHP's functionality, and which are the
bread-and-butter of many PHP projects -- get second-class status when it
comes to autoloading?
I can see an autoloader like this:
function autoloadFunctions($funcname, $type = SPL_AUTOLOAD_FUNCTION)
{
if (!strstr($funcname, '\\')) {
// we won't deal with un-namespaced functions
return false;
}
$namespace = substr($funcname, 0, strrpos($funcname, '\\'));
$funcfile = str_replace('\\', DIRECTORY_SEPARATOR, $namespace)
. `DIRECTORY_SEPARATOR` . 'Functions.php';
return include_once($funcfile);
}
and that might autoload all functions in a given namespace. I've seen
other projects that put a function per-file -- so those might become
even more granular.
Basically, I don't see why we wouldn't want this functionality in PHP.
It makes namespaces practical and useful for procedural applications.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Hello,
On Mon, Aug 15, 2011 at 2:30 PM, Matthew Weier O'Phinney
weierophinney@php.net wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
I must say a few of the suggestions I have seen appear a bit odd,
however I believe that the proposed RFC suggestion using SPL is
perfectly in alignment with how I would expect auto-loading to work.
This would be a nice feature to have for a lot of code bases I am
sure.
-Chris
Hi,
With this mail I don't want to talk to anyone directly, but I just want
to summarize the situation as far as I understand.
- Autoloading constants
No problem here: When the loading procedure fails, it gets converted to
a string like before. It may be a performance impact, but the code, that
relies on this "feature" gets flooded with warnings anyway.
- Autoloading functions
If I understood it right the only problem is, that someFunction() may
be in the global, as well as in the current namespace. This means, the
developer write a function in a namespace, that already exists in the
global scope, which remains to feel quite scary to me. Its way more
confusing, that (e.g.) strpos() don't behave, like expected and
learned for years now.
It will affect only single namespaces, because if you want to call a
function from another namespace you must prefix it with a qualified or
full-qualified namespace anyway.
And last but not least: Currently you must include the files containing
the functions yourself. This means, that existing code is not
affected, because as long as no one removes the include-statements, it
even not call any autoloading. But when the developers decides to remove
them, they probably wants to use the autoloading, what means, that they
(hopefully) understand, how it works.
However, in my opinion the important part is to just make a decision the
sooner, the better, as long as there are not too much creepy code out
there (I don't know any and I can't imagine, that there is). Because
functions with namespace are quite unhandy without autoloading and I
don't think, that there is much use of it.
So the 2 possible solutions:
1:
- test namespace
- test global
- load namespace
- load global
2:
- test namespace
- load namespace
- test global
- load global
Maybe
3:
- test namespace
- test global
- load global
- load namespace
would be a solution too, but it seems a little bit curious, when I use
namespaces, but it looks into the global scope first.
Regards,
Sebastian
Am 06.08.2011 13:15, schrieb Ferenc Kovacs:
Hi.
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
Hi,
Hi,
With this mail I don't want to talk to anyone directly, but I just want to
summarize the situation as far as I understand.
- Autoloading constants
No problem here: When the loading procedure fails, it gets converted to a
string like before. It may be a performance impact, but the code, that
relies on this "feature" gets flooded with warnings anyway.
- Autoloading functions
If I understood it right the only problem is, that someFunction() may be
in the global, as well as in the current namespace. This means, the
developer write a function in a namespace, that already exists in the global
scope, which remains to feel quite scary to me. Its way more confusing, that
(e.g.) strpos() don't behave, like expected and learned for years now.It will affect only single namespaces, because if you want to call a
function from another namespace you must prefix it with a qualified or
full-qualified namespace anyway.
And last but not least: Currently you must include the files containing the
functions yourself. This means, that existing code is not affected,
because as long as no one removes the include-statements, it even not call
any autoloading. But when the developers decides to remove them, they
probably wants to use the autoloading, what means, that they (hopefully)
understand, how it works.However, in my opinion the important part is to just make a decision the
sooner, the better, as long as there are not too much creepy code out there
(I don't know any and I can't imagine, that there is). Because functions
with namespace are quite unhandy without autoloading and I don't think, that
there is much use of it.So the 2 possible solutions:
1:
- test namespace
- test global
- load namespace
- load global
2:
- test namespace
- load namespace
- test global
- load global
Also:
4:
- test namespace
- test global
- load namespace
Maybe
3:
- test namespace
- test global
- load global
- load namespace
would be a solution too, but it seems a little bit curious, when I use
namespaces, but it looks into the global scope first.Regards,
SebastianAm 06.08.2011 13:15, schrieb Ferenc Kovacs:
Hi.
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.--
--
Etienne Kneuss
http://www.colder.ch
Hi!
However, in my opinion the important part is to just make a decision the
sooner, the better, as long as there are not too much creepy code out
there (I don't know any and I can't imagine, that there is). Because
functions with namespace are quite unhandy without autoloading and I
don't think, that there is much use of it.
We already made the decision, when we introduced the namespaces and made
the resolution order what it is now. And we considered all the variants
and discussed all the arguments brought here back then.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
However, in my opinion the important part is to just make a decision the
sooner, the better, as long as there are not too much creepy code out
there (I don't know any and I can't imagine, that there is). Because
functions with namespace are quite unhandy without autoloading and I
don't think, that there is much use of it.We already made the decision, when we introduced the namespaces and made the
resolution order what it is now. And we considered all the variants and
discussed all the arguments brought here back then.
could you link the discussion about the function autoloading back then?
I only found the namespace resolution discussion, but nothing about
functions, except that they should fall back to the global namespace
as we don't have/didn't have autoloaders for them.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu