On 8/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Read the purpose of both, which restrictions/limitations both have,
> > how are they defined, how are they used, etc and you'll see if the
> > current implementation is more like 'namespace' or 'package'. It's not
> > related to package Java, namespace C, def, zendspace of whatever.
>
> That's what I am trying to explain for a week now and still failing.
> Namespace as a concept is not the same as implementation of namespaces
> in C++ or Java. Packages as a concept is not the same as implementation
> of packages in Java, Perl, C or PHP. PHP is neither C++ not Java.
> Choosing which language to mimic - Java or C++ - is not the right way to
> think about the problem. PHP is separate language, not C++ or Java. Just
> because C++ has + and PHP has + doesn't mean PHP should have operator
> overloading. Just because PHP has multi-component names and Java has
> multi-component names doesn't mean namespace definition operator should
> be the same keyword. That's what I'm trying to explain - the choice is
> not "should we be like C++ or like Java". We may end up being like it -
> or not, but it is not the choice we have.
>
That's why I purposed the unique name. Also it follows the Gregory not
so likely email.
You can use zendspace. (Gregory) If you want me to get Johannes patch
and convert it to zendspace, just tell me.
> > - Allow nested definitions namespace N1 { namespace SubN1 { ... }
> > namespace Sub2N1 { ... } }
>
> That most probably won't happen ever. If you want to know why, look up
> the nested class saga. In short - too much trouble to implement
> consistently, too bad runtime performance (unlimited lookup depth at
> runtime).
>
That's what I imagine it happens, otherwise that was no reason to not
allow more than one namespace/package per file.
> > not in packages). You tell me 'namespace' are unique. I agree, but
> > 3rdparty libraries using the name namespace alias will still mess the
> > entire application. So let's follow bjori (IRC) idea and create the
> > "filescope"!
>
> I'm afraid I don't understand - what would filescope do?
The reason to something like that is when you do:
import Foo::Bar as MyBar;
$c = new MyBar::NestedClass();
This can still cause a conflict.
Let me try to illustrate with a real world example (but hypotetical).
I use Zend Framework and at the same time ADOdb. Both has its
namespaces/packages:
namespace/package/zendspace/whatever Zend::DB;
class Connection { ... }
namespace ADO::DB;
class Connection { ... }
Internally in the Zend framework (in a class definition, for exmaple),
it can use:
package Zend::Foo;
import Zend::DB as DB;
$c = new DB::Connection();
And internally in the ADO package:
namespace ADO::Bar;
import ADO::DB as DB;
$c = new DB::Connection();
What will happen in this situation?
The idea of file scope works like this:
If it's internal to a package/namespace, that alias is restricted to
THAT package/namespace. If it's not internal to any space, it's global
and can be used as expected.
I think my idea is better explained with an example:
File: ORM/Client.php
<?php
namespace ORM
// Assign namespace in localscope (file scope, based on PHP implementation)
import System; // Contains Console class which controle I/O, like C#
class Client {
function __construct() {
Console::println( "Client created!" );
}
}
?>
File: index.php
<?php
// Console directly is unreachable, you must do this:
System::Console::println( "Unreachable" );
// Or import System again to allow it in global scope
import System;
Console::println( "Reachable now!" );
?>
Do you understand the idea now? I can try to explain differently if needed.
Regards,
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8829 MSN: [EMAIL PROTECTED]
>
>
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
São Carlos - SP/Brazil
