import Name::Space; // only stuff from Name::Space available, no PHP internal stuff import __php__; // now PHP's classes are loaded, too.
So "import php" make internal classes always take priority even when there's a class in this namespace by that name? But you could achiever the same just by avoiding naming classes the same as internal classes, you surely know which classes are in your own namespace? Since in both cases code change is needed, why that one is better? If you created Name::Space::DateTime, surely there was some intent in having it named specifically the same as DateTime class in PHP?
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
Not using names of classes same as internal classes is not a big deal either - all PHP programmers do it right now :) I just don't see any added value in inventing artificial syntax constructs which don't do what they implied meaning is (they don't import anything) but instead change engine rules.
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.
Java package system is very different. For starters, they don't have global space at all. And they have offline compilation stage which verifies all the dependencies.
I don't think that PHP's internal stuff needs to be magically available. We can force developers to explicitly request access to it.
We can, but we should not. Internal classes are internal for a reason - people use them a lot. Making it hard to access frequently used classes to enable rarely used functionality is not the right way to go.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
