On 05.11.2008, at 21:24, Stanislav Malyshev wrote:
Hi!
Well, its not like the person is getting Y when he is expecting X.
Both classes have the same name after all, so there is some
relation between
They don't have the same name - two classes can't have the same
name. And "relation" is definitely not enough - you really do not
ok, they have the same non fully qualified named.
want to get generic \Exception instead of \My\Very\Specific
\Exception - it would probably break all your error handling.
this is about overloading and flexibility.
these two classes. More importantly its the users choice to enable
this in __autoload(). As all frameworks got that its the end users
job to implement autoload, I would not worry soo much in this case.
I do not see a need for autoload to substitute different classes
instead of ones that are requested. autoload has very specific
function - to load classes. To override it with tricks that
substitute one class for another is the runkit domain, and IMHO
should stay there. It would seriously complicate matters everywhere
(if you load the class, you can no longer be sure successful loading
have indeed loaded you the class you asked for!) and appears
completely unnecessary hack.
the point was that this gives the end user the choice of when, if at
all, to fallback to the global namespace. in this way the default
could indeed be 1) ns 2) autoload 3) fail. just that autoload can now
handle more cases in a manner the end users might deem sensible.
i guess the other alternative (though actually i am not sure if its
possible), that people will likely try out is to extend the base class
inside the namespace on the fly. which i would consider much worse.
this might or might not be a sensible compromise, but you would do us
all a favor if you would stop killing off open thinking with useless
metaphors about 85 year old ladies.
thanks ...
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
