[PHP-DEV] Re: Namespace resolution rules has been changed?
David Grudl napsal(a):
Hello!
This code leads to fatal error: Class 'Nette\Loaders\Nette\Object'. Is
it a bug in current implementation or namespace resolution rules has
been changed?
namespace Nette;
class Object
{}
namespace Nette\Loaders;
class AutoLoader extends Nette\Object
{}
$obj = new AutoLoader;
Thank you,
David Grudl
I'm maybe wrong but I think that namespace resolution rules has been
changed. This should work:
namespace Nette\Loaders;
class AutoLoader extends \Nette\Object
{}
Regards,
Jaroslav Hanslík
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
Jaroslav Hanslík wrote:
> David Grudl napsal(a):
>> Hello!
>>
>> This code leads to fatal error: Class 'Nette\Loaders\Nette\Object'. Is
>> it a bug in current implementation or namespace resolution rules has
>> been changed?
>>
>> namespace Nette;
>>
>> class Object
>>
>> {}
>>
>> namespace Nette\Loaders;
>>
>> class AutoLoader extends Nette\Object
>>
>> {}
>>
>> $obj = new AutoLoader;
>>
>>
>>
>> Thank you,
>> David Grudl
>
> I'm maybe wrong but I think that namespace resolution rules has been
> changed. This should work:
>
> namespace Nette\Loaders;
>
> class AutoLoader extends \Nette\Object
> {}
Hi,
The resolution rules have changed in that way. The reason was an
inconsistency:
versus this code:
The problem was that it isn't immediately clear why we would consider
"Sub\Object" to be the same as "\Sub\Object", but "Object" to be
different from "\Object" inside a namespace context, but the same
outside a namespace context.
This is an important thing for developers of namespaced code to realize.
The docs have been updated in my personal checkout of php-doc, and I am
revising them to make them clearer, and also waiting on a few other
details to make it into CVS before committing.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
The problem was that it isn't immediately clear why we would consider "Sub\Object" to be the same as "\Sub\Object", but "Object" to be different from "\Object" inside a namespace context, but the same outside a namespace context. The "Sub\Object" should be understand as fully qualified identifiers and thus considered as the same as "\Sub\Object". I understand this new behaviour is same as using "relative paths", but there is a common best practise to not make dependencies form topper namespaces to deeper ones. So it is rare to have class Company\Software\Base extending Company\Software\Web\Forms\Control (i.e. Base extends Web\Forms\Control), and it is common have class Company\Software\Web\Forms\Control extending Company\Software\Base. So in real world it means that nearly every usage of "partially qualified indentifiers" (Sub\Object) have to be written with preceding backslash. David Grudl My english is poor but I hope you understand me ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
> Can you please point us to an example describing this best practice? For example Namespace Naming Guidelines in .NET (http://msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx) "A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design." Or Zend Framework source code. There is no class extending class from subpackage (class Zend_View extends Zend_View_Abstract is not subpackage, viz http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). * > *In PHP nothing bubbles, hence this doesn't work. We have just one exception to this, with global functions in local space which "bubble up" to global even without the prefix (which I believe will come to bite us later on). * *I understand but I think it doesn't matter. PHP has not qualified identifiers yet, so any qualified identifier can be understand as and only as fully qualified identifier (ie "absolute path"), like former namespace implementation does, and not like "relative path". David Grudl
[PHP-DEV] Re: Namespace resolution rules has been changed?
Původní zpráva Předmět: Re:Namespace resolution rules has been changed? Od: David Grudl <[EMAIL PROTECTED]> Datum: 10.11.2008 23:53 > Can you please point us to an example describing this best practice? For example Namespace Naming Guidelines in .NET (http://msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx) "A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design." Or Zend Framework source code. There is no class extending class from subpackage (class Zend_View extends Zend_View_Abstract is not subpackage, viz http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). * * And another example is Nette Framework, maybe the first PHP framework ready to use namespaces. Nowhere in the code is the place where "relative qualification" would be useful. On the contrary, in all places you is needed "full qualifications". Obligation to use the slash is just a pain. DG.
[PHP-DEV] Re: Namespace resolution rules has been changed?
David Grudl wrote: > Původní zpráva > Předmět: Re:Namespace resolution rules has been changed? > Od: David Grudl <[EMAIL PROTECTED]> > Datum: 10.11.2008 23:53 >> > Can you please point us to an example describing this best practice? >> >> For example Namespace Naming Guidelines in .NET >> (http://msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx) >> >> "A nested namespace should have a dependency on types in the >> containing namespace. For example, the classes in the >> System.Web.UI.Design depend on the classes in System.Web.UI. However, >> the classes in System.Web.UI do not depend on the classes in >> System.Web.UI.Design." >> >> Or Zend Framework source code. There is no class extending class from >> subpackage (class Zend_View extends Zend_View_Abstract is not >> subpackage, viz >> http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). >> >> * >> * > > And another example is Nette Framework, maybe the first PHP framework > ready to use namespaces. Nowhere in the code is the place where > "relative qualification" would be useful. On the contrary, in all > places you is needed "full qualifications". Obligation to use the slash > is just a pain. Hi, let's look at this code: There are a few things to keep in mind. PHP has __autoload(), which C# does not have. Thus, a solution such as: 1) try foo\classes\foo\stuff 2) try foo\stuff does not work because we get double-autoload call for foo\stuff, which is a hidden performance penalty. This means we can't quietly resolve qualified class names as if they were fully qualified and continue to support the other method. In addition, in spite of your examples, this is a common language principle, and I found that both C++ and C# have clear examples in their manuals of similar resolution rules to what PHP has. They use it for accessing sub-namespaces: http://www.java2s.com/Tutorial/Cpp/0020__Language-Basics/Anestednamespace.htm http://msdn.microsoft.com/en-us/library/z2kcy19k(VS.80).aspx In addition, C# has a disambiguation method for specifying fully qualified class name when there is another name that conflicts in the namespace: prefix "global::" to it. http://msdn.microsoft.com/en-us/library/c3ay4x3d(VS.80).aspx Obviously, prepending a single backslash is far preferable to something like prepending "global::". Finally, as a last point, you will have to prepend \ to all global classes anyways (and this can't be changed), how is this any different from prepending \ to class names that are\like\this? We introduce a language inconsistency by treating short and long names arbitrarily differently, especially because import rules are applied to *all* qualified names unless they start with \. For instance: Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
Greg Beaver wrote:
>
> namespace foo\classes;
> use sneaky\devil as foo;
>
> class buh extends foo\stuff {}
> \\ this extends sneaky\devil\stuff. oops... should have used \foo\stuff
> ?>
accualy I have a question about this if i may: why doesn't the use statement
fall under the same resolution rules as general code? that is why foo isn't
foo\classses\sneaky\devil?
personally i'd find this much more consistent if *anything* below namespace
declaration was relative to it. and i could always use absolute declaration
explicitly if i'd require it:
resolves as A == \foo\bar
use \bar as B; /// ->resolves as B == \bar
?>
TIA
m.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
Marcin Kurzyna wrote:
>
> namespace foo;
>
> use bar as A; /// ->resolves as A == \foo\bar
> use \bar as B; /// ->resolves as B == \bar
>
> ?>
Hi Marcin,
Stan also requested this, so it should be considered as a possibility.
Personally, I would rather not introduce this land mine. It requires
the user to do an implicit prepending of namespace name ("foo") to "bar"
in the use statement as well as a translation of "A", which could fast
lead to unreadable code.
It is probably best to simply require a fully qualified name where it is
intended. Thus
1) require leading "\" in use statements
2) allow "namespace\blah" in use statements, as this is a valid fully
qualified name.
Stas, I'm sure you have an opinion on this?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
let's look at this code: There are a few things to keep in mind. PHP has __autoload(), which C# does not have. Thus, a solution such as: 1) try foo\classes\foo\stuff 2) try foo\stuff Greg, this is clear. I am trying to point something different - to try ONLY 2) and never try 1). Why? I have developed framework using PHP namespaces and studied Zend Framework source codes and result is: if we use the new resolution rules (1), than in nearly all cases developers must prefix class names with \, only in few cases prefix is not required. Why? Because usually classes in more nested namespaces extends classes in less nested namespaces. If you don't believe, look in framework sources :-) So, resolution alá 1) is nearly in all cases pain and in few cases nice, resolution alá 2) is nearly in all cases nice and in few cases not too nice. Furthermore, resolution alá 1) means, that namespace named foo\stuff is fiction - there is only namespace named \foo\stuff. Lets use \foo\stuff everywhere: namespace \foo\classes; use \foo\stuff as stuff; This is (at least) very ugly. David p.s. Save useless backslashes, save a peace :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
David Grudl wrote: > Why? I have developed framework using PHP namespaces and studied Zend > Framework source codes and result is: if we use the new resolution rules > (1), than in nearly all cases developers must prefix class names with \, > only in few cases prefix is not required. Why? Because usually classes > in more nested namespaces extends classes in less nested namespaces. If > you don't believe, look in framework sources :-) > > So, resolution al?? 1) is nearly in all cases pain and in few cases nice, > resolution al?? 2) is nearly in all cases nice and in few cases not too > nice. true, however i have a counter example: classes from more general namespace that use further nested classes (think some kind of behaviour and different drivers/plugins for example). so while it's true that more nested classes usually extend the less nested ones it also common for more generic code to use it's namespace descendants. in sutch condition possibility to use just the remaining namespace part is a big help and i'd say it's usage would be more comon than single "extends" at class definition where you're obligated to supply FQN [1]. > > Furthermore, resolution al?? 1) means, that namespace named foo\stuff is > fiction - there is only namespace named \foo\stuff. Lets use \foo\stuff > everywhere: i second that (at least when FQN is used) - would provide more consistency. m. [1] FQN: fully quallified name -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
true, however i have a counter example: classes from more general namespace that use further nested classes (think some kind of behaviour and different drivers/plugins for example). so while it's true that more nested classes usually extend the less nested ones it also common for more generic code to use it's namespace descendants. in sutch condition possibility to use just the remaining namespace part is a big help and i'd say it's usage would be more comon than single "extends" at class definition where you're obligated to supply FQN [1]. The more generic code (i.e. application code) is located usually in its own namespace, so it must use FQN. FQN with leading backslash. DG. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
Try to answer the question: what is the $obj instance of?
namespace foo;
$obj = $factory->loadClass('bar\class');
---
$factory is implemented cca this way:
namespace ?;
class Factory
{
function loadClass($class) {
return new $class;
}
}
With absolute FQN is the answer evident. With relative FQN it is very
esoteric.
With relative FQN developers will have to implement "save" loadClass()
this way:
function loadClass($class)
{
if (strpos($class, '\\') !== FALSE && strncmp($class, '\\', 1)) {
$class = '\\' . $class;
}
return new $class;
}
OMG
David Grudl
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
I understand this new behaviour is same as using "relative paths", but there is a common best practise to not make dependencies form topper namespaces to deeper ones. So it is rare to have class Company\Software\Base extending Company\Software\Web\Forms\Control (i.e. Base extends Web\Forms\Control), and it is common have class Company\Software\Web\Forms\Control extending Company\Software\Base. So in real world it means that nearly every usage of "partially qualified indentifiers" (Sub\Object) have to be written with preceding backslash. David Grudl Can you please point us to an example describing this best practice? Aside from this, the problem is: scopes. In other languages we don't have preceding separators and those conflicts hence don't exist, since with scopes, if a name doesn't exist in the local scope, it's automatically bubbled up until it goes right back to the global scope. In PHP nothing bubbles, hence this doesn't work. We have just one exception to this, with global functions in local space which "bubble up" to global even without the prefix (which I believe will come to bite us later on). However there's still one more issue, "use" clauses only understand full symbol names, which causes yet another inconsistency: namespace foo; use bar\baz as bar_baz; $a = new bar\baz(); //instantiates class with absolute path "foo\bar\baz" $b = new bar_baz(); //instantiates class absolute path "bar\baz" In fact, use doesn't even know what the prefix would mean: use \bar\baz; // parse error So it has to be decided which way the system goes to avoid confusion and bugs IMO. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Or Zend Framework source code. There is no class extending class from subpackage (class Zend_View extends Zend_View_Abstract is not subpackage, viz http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). * > *In PHP nothing bubbles, hence this doesn't work. We have just one exception to this, with global functions in local space which "bubble up" to global even without the prefix (which I believe will come to bite us later on). * *I understand but I think it doesn't matter. PHP has not qualified identifiers yet, so any qualified identifier can be understand as and only as fully qualified identifier (ie "absolute path"), like former namespace implementation does, and not like "relative path". David Grudl The Zend Framework is chock full of classes reaching for inner classes and providing them to the world in the form of Adapters, Factories, Drivers, etc. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Hi Marcin,
Stan also requested this, so it should be considered as a possibility.
Personally, I would rather not introduce this land mine. It requires
the user to do an implicit prepending of namespace name ("foo") to "bar"
in the use statement as well as a translation of "A", which could fast
lead to unreadable code.
It is probably best to simply require a fully qualified name where it is
intended. Thus
1) require leading "\" in use statements
2) allow "namespace\blah" in use statements, as this is a valid fully
qualified name.
Greg, I can't spot where does your example differ from what I and Marcin
suggested? Please explain.
As for the leading \ for fully qualified identifiers, well it's a necessary
evil. As you said yourself PHP is PHP, and we have unique constraints to
meet, we have no scopes, we have no compile time packaging of the resources,
and since we don't have meta files describing the namespace resources (wink
wink...), we should stick to a single-rule no-ambiguity system.
For me the only way to make it clear to both humans and parsers alike is the
filepath semantics, in all places, including use. It's not perfect, there's
no completely problem-free solution, but "prepend \ for absolute path" is
able to become muscle memory, while other mixed solutions I've seen are more
confusing and require more thinking: "wait in this context what was what?".
And there's one more pain point which I posted earlier on the list about,
but now as I prepare my framework for 5.3 namespaces, I *really* feel the
pain in practice: the inability to pass a class/function name without
specifying it fully as a string.
My suggestion was: use foo\bar\baz as alias;$name = nameof alias; //
$name == 'foo\bar\baz'
But this introduces a new keyword: nameof, which could clash with
function/class/constant "nameof" in existing source code. I could suggest
simply not having "nameof" and having direct assignment assign the class
name, but then we clash with constants which have the same name as the
class. So that's not doable either.
But it's definitely in-your-face issue while using namespaced code.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Stan Vassilev | FM wrote:
>> Hi Marcin,
>>
>> Stan also requested this, so it should be considered as a possibility.
>>
>> Personally, I would rather not introduce this land mine. It requires
>> the user to do an implicit prepending of namespace name ("foo") to "bar"
>> in the use statement as well as a translation of "A", which could fast
>> lead to unreadable code.
>>
>> It is probably best to simply require a fully qualified name where it is
>> intended. Thus
>>
>> 1) require leading "\" in use statements
>> 2) allow "namespace\blah" in use statements, as this is a valid fully
>> qualified name.
>>
>> > namespace my\ns;
>>
>> // this is a better way to do the suggested "use bar as A;"
>> use namespace\bar as A;
>> use \bar as B;
>>
>> class mine extends \my\parentclass {}
>> ?>
>
> Greg, I can't spot where does your example differ from what I and Marcin
> suggested? Please explain.
I would not allow "use blah\blah as bar;"
> And there's one more pain point which I posted earlier on the list
> about, but now as I prepare my framework for 5.3 namespaces, I *really*
> feel the pain in practice: the inability to pass a class/function name
> without specifying it fully as a string.
>
> My suggestion was: use foo\bar\baz as alias;$name = nameof alias;
> // $name == 'foo\bar\baz'
Are you aware of __NAMESPACE__? Also, if you are using a lot of
external namespace names, you might consider simply defining constants:
namespace foo\bar\baz;
const ns = __NAMESPACE__;
then you can simply do
use foo\bar\baz; $name = baz\ns;
I don't see a huge pressing need for nameof since the above is 3 extra
lines of code - total - per NS.
If this sounds good, I will add an example to the new docs
yet-to-be-committed.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
"Stan Vassilev | FM" wrote: > For me the only way to make it clear to both humans and parsers alike is > the filepath semantics, in all places, including use. It's not perfect, > there's no completely problem-free solution, but "prepend \ for absolute > path" is able to become muscle memory, while other mixed solutions I've > seen are more confusing and require more thinking: "wait in this context > what was what?". My point exactly. This was a real pain in the ass while converting from old to new resolution rules (though I now this is a one-time example). However i was explaining the new resolution rules to my co-workers recently and it was aparent the context dependant resolution isn't clear, while understanding: "it's always relative to current namespace" is simple and easy. Also most people are familiar with filepath semantics so there is a obvious point of reference (and confusion when it's not consistent). > But this introduces a new keyword: nameof, which could clash with > function/class/constant "nameof" in existing source code. I could suggest [...] > But it's definitely in-your-face issue while using namespaced code. I'm not shure how big of a problem "nameof" clashing would be, however a way to get fully qualified name is a nessesity in my opinion - i strugle with this in my framework too. Gregs suggestion of __NAMESPACE__ concatenated solution (if i understand it correctly) isn't one accualy because __NAMESPACE__ resolves to current namespace; and "typeof" might (and probably usually will) be used on aliased classes not nessecerely from current namespace. m. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Are you aware of __NAMESPACE__? Also, if you are using a lot of external namespace names, you might consider simply defining constants: namespace foo\bar\baz; const ns = __NAMESPACE__; then you can simply do use foo\bar\baz; $name = baz\ns; I don't see a huge pressing need for nameof since the above is 3 extra lines of code - total - per NS. If this sounds good, I will add an example to the new docs yet-to-be-committed. Greg I'm aware of __NAMESPACE__, and your example is kinda creative, but I think that's a touch too much acrobatics for something that's a basic need :P Consider callbacks, factories, strategies, drivers, adapters, proxies and so on which typically may and do pass class/function names around. I don't know. I'd rather endure the pain and write the string in full every single time than cause extra confusion in my source code :) Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Why? I have developed framework using PHP namespaces and studied Zend Framework source codes and result is: if we use the new resolution rules (1), than in nearly all cases developers must prefix class names with \, only in few cases prefix is not required. Why? Because usually classes in more nested namespaces extends classes in less nested namespaces. If you don't believe, look in framework sources :-) A quick study on the Zend Framework source reveals most top-level classes requiring, using, and accepting as arguments "more inner" classes and interfaces in the relevant namespace: Zend_Acl ==> Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface, Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry... Zend_Auth ==> Zend_Auth_Storage_Session, Zend_Auth_Storage_Interface, Zend_Auth_Adapter_Interface... Zend_Cache ==> Zend_Cache_Core, Zend_Cache_Frontend, Zend_Cache_Backend (including all specific frontend/backend adapters). Zend_Db ==> it's a factory for all classes like: Zend_Db_Adapter_* Zend_Pdf ==> Zend_Pdf_Page, Zend_Pdf_Cmap, Zend_Pdf_Font, Zend_Pdf_Style, Zend_Pdf_Parser, Zend_Pdf_Trailer, Zend_Pdf_Color etc. So, I really suggest we leave that argument out. Regard, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
David Grudl wrote:
> Try to answer the question: what is the $obj instance of?
>
> namespace foo;
> $obj = $factory->loadClass('bar\class');
bar\class
dynamic class names are always FQN.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
> > Why? I have developed framework using PHP namespaces and studied Zend > > Framework source codes and result is: if we use the new resolution rules > > (1), than in nearly all cases developers must prefix class names with \, > > only in few cases prefix is not required. Why? Because usually classes in > > more nested namespaces extends classes in less nested namespaces. If you > > don't believe, look in framework sources :-) > > A quick study on the Zend Framework source reveals most top-level classes > requiring, using, and accepting as arguments "more inner" classes and > interfaces in the relevant namespace: > > Zend_Acl ==> Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface, > Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry... > > Regard, Stan Vassilev Stan, ZF doesn't use namespaces yet. This is not namespaced code. Namespaced code requires different convention (http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). In namespaced code there cannot be class Interface in namespace Zend\Acl\Role. There must be class RoleInterface in Zend\Acl namespace. Similary class Zend_Acl become Acl in Zend\Acl namespace. So look at the code with namespace-eyes. Classes Zend_Acl, Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface... will exist in one namespace. Every concrete plugins extending Zend\Controller\AbstractPlugin may exists in namespace Zend\Controllers\Plugins. Classes in Zend\Controller may not use classes in Zend\Controllers\Plugins (more abstract/common may not use concrete plugins), but plugins in Zend\Controllers\Plugins depends on classes in Zend\Controller. The "dependency-direction" should be one way. DG. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
> Zend_Acl ==> Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface, > Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry... > > Regard, Stan Vassilev Stan, ZF doesn't use namespaces yet. This is not namespaced code. Namespaced code requires different convention (http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). In namespaced code there cannot be class Interface in namespace Zend\Acl\Role. There must be class RoleInterface in Zend\Acl namespace. Similary class Zend_Acl become Acl in Zend\Acl namespace. So look at the code with namespace-eyes. Classes Zend_Acl, Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface... will exist in one namespace. I've checked that wiki page before, and I'm following with interest how they end up naming those, but that changes nothing. Today, Zend_Acl uses Zend_Acl_Resource_Interface. Tommorow, Zend\Acl uses Zend\Acl\ResourceInterface (or similar). The fact is, PHP frameworks and especially Zend use plenty of factories and facade classes, which by definition reach into inner-more classes and provide simplified paradigm to the "outside world". The Interface and Exception classes won't stay like this, but they'll still be inside a subnamespace. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed
I have downloaded last Mono source code (http://www.mono-project.com/, version 2.0.1), the open source version of one of the most complex and mature framework in the world, the .NET framework. Framework is written using namespaces (as opposite to current version of Zend). And I have analysed source codes. The results are: Directory /mcs/class/ Files: 11500 Namespace: 529 Class extends from "more inner" class: 4 Function accepting as arguments "more inner" classes: 0 Count of using clauses: - nested: 1031 - non-nested: 34673 (34 times more!) If you agree, that 34673 > 1031, please revert namespace behaviour back to alpha2. The 34times more developers will thank you ;) DG. p.s. if you'd like, I send you source code of analyzer. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
