On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote:
Hi
I have tried to collect the various opinions on resolution order
into a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of
function/constants would affect the question of namespace resolution
order choices. Lets not use this to get back on to the topic of the
namespace separator and instead focus on the namespace resolution
for now. First lets get an RFC that documents all approaches for
namespace resolution in perfect shape. Divide and conquer.
Furthermore, we have all noticed that the participation on the list
has increased a lot in the recent weeks. As a result I ask everybody
to restrain themselves a bit more. Try to not reply on an impulse,
maybe wait a few hours before posting. This way we might reduce
redundant replies, also the quality of posts will hopefully be
higher so less misconceptions will need to be cleared later (and
misconceptions have a way to spiral into flamewars).
Some people have told me that they found the RFC hard to read.
Unfortunately this is not the first time that I have gotten feedback
like this from an RFC/FAQ I have written. If anyone has some
suggestions for improvements please let me know.
I have also just added another approach to the RFC. Instead of loading
classes as follows:
1) ns
2) autoload
3) global
one could also do
1) ns
2) global
3) autoload
this would prevent the issue with performance that Stas pointed out.
it would also retain the concept that autoload is a last resort
attempt (i guess some people even define classes in the fly if they
cannot be found elsewhere to be able to handle errors or even download
code when needed).
this would obviously mean that when someone wants to intentionally
overload a class, its important to either use the fully qualified name
or ensure that the class definition is loaded before use (similar
situation as we have with functions/constants if we do have the
fallback).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
