Hi!
As you know, with the new convention, the parser will not encounter
T_STRING "Zend\Validate\Interface" but rather:
With namespaces, class name would not be Zend\Validate\Interface. Having
namespaces, it would make much more sense to make last component a
descriptive name, so you won't have code like this:
if($object instanceof Interface) { // wtf am I checking here?
...
As for how exactly that descriptive name should look - I guess each
framework's developers that plan to support namespaces think about it hard
right now. I know ZF developers do :)
Hi,
Fully agreed. Though since we (PHP users) will all be using namespaces
together, it makes much more sense that we have a paradigm, recommendation
for namespace usage that all frameworks will follow.
Maybe the ZF, Agavi, CI, CakePHP etc. authors should get together and craft
a single recommendation list for people to use.
It's not just a matter of consistency, it's a matter of makming the language
work well with the recommended scenario and use patterns of namespaces.
Two things are obvious:
1) What worked with underscores won't work with namespaces.
2) What scenario above with "instanceof Interface" isn't very likely. Why?
Well imagine you want to use 5 classes in namespace foo\bar, called A, B, C,
D, E (ex. foo\bar\A). In most any language with packaging system, to flatten
the space you simply do this:
use foo\bar\*;
$a = new A();
$b = new B();
...
In PHP, due to lack of packaging system and knowledge of the user resources
at parse time, instead we're painfully explicit:
use foo\bar\A;
use foo\bar\B;
use foo\bar\C;
use foo\bar\D;
use foo\bar\E;
$a = new A();
$b = new B();
Which makes this usage pattern with aliases much more likely to see:
use foo\bar as fb;
$a = new fb\A();
$b = new fb\B();
So your example above would rather be:
use Zend\Validate as ZV;
... instanceof ZV\Interface;
And this is why it's worth it to arrive at a single list of recommendations
for namespace usage, and see what works there and what might not work, and
tweak the language for it.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
