Am 11.12.2007 um 22:31 schrieb Stanislav Malyshev:
You would now have to go through all ten autoloaders before you can
decide that no userspace class DateTime exists in any namespace,
and thus the PHP internal class DateTime may be used.
Even one autoloader is bad enough to not even have to consider the
case of ten autoloaders. Remember, autoloader is filesystem access.
Filesystem access on each class mention is a disaster.
like a fool when you're tired of coming up with arguments. You very
well know I meant "import". Reply to the suggestion in a respectful
manner, or give it a miss.
I'm afraid I still do not understand what did you mean. Could you
explain in more detail?
Sure. My basic idea was that since the issue we're talking about can
only occur either in namespaced code, or in code that uses namespaced
components, there would not be any backwards compatibility problem
with something like:
import Name::Space;
// only stuff from Name::Space available, no PHP internal stuff
import __php__;
// now PHP's classes are loaded, too.
$d = new DateTime(); // this loads __php__'s DateTime, since the first
existance check gives that one, so no autoloading is ever performed,
even if there is a Name::Space::DateTime class.
Now, assuming that someone wants to use PHP stuff _and_ Name::Space
stuff of the same name, they can do import __php__ as __php__; (or
import Name::Space as NS and then new NS::DateTime()) for either
statement to work around that. In any case, it would never introduce
issues. My statement 'doing a "use __php__" is not a tall
order' (which means it's not asking much from the developer to do
that) from one of the previous mails was referring to just that. Think
of other languages with namespace/package concepts. If you want to use
java's date/time features, you need to do some kind of import
java.util.blah stuff, too. I don't think that PHP's internal stuff
needs to be magically available. We can force developers to explicitly
request access to it.
Did that explanation help? :)
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
