>  Your answered like "We are not like C#, but we are like Python.". I'm
>  not the one that will point that Python always try to be a unique
>  language or will criticize you.

We are not like Python either, really. We try to do what's best for PHP 
with it's unique history, usage patterns and problems. We tried to think 
of a way to copy other language's model, it didn't work out well. PHP is 
different enough to need custom solution.

>  The topic is always entitled as "block scope".
>  Since namespace is a block scope too, so it's a commom sense. It's
>  easier to read, easier to understand, etc.

That's not correct - namespace is not a scope. Namespace is a naming 
convention and a syntax which allows to use this naming convention 
conveniently. That's because it is meant to solve naming problem, not 
scoping problem.

>  If PHP supports more than one namespace per file, why not provide it
>  to developers? It's a functionality, not a bug. Do not restrict
>  functionalities because you do not like them.

That's exactly what we do, what all high-level languages do. We don't 
like people being able to access random memory location as in C/C++, so 
we restrict it. We don't like people to be able to access any member of 
the class from anywhere, so we restrict that. We don't like particular 
function to work on any object but only on objects of specific type, so 
we restrict that. And so on.

>  That's my final point, and my last try to talk about braces. Seems you
>  do not like external ideas.

I'm not sure I like this one particular idea. Though if I see many 
developers needing it, I very well might reconsider it.

>  It saves the time needed to include all the files and also the memory
>  that it saves for calling require_once, include_once, etc.

That's why one needs to use bytecode cache :)

>  I think it's overload. Someone mentioned earlier and I was curious if
>  you implemented this or not.

You mean like having this function be called whenever strlen is called? 
I don't think it's a very good idea, high WTF factor.

> > For 100th time, import Foo is a no-op. I'm thinking about prohibiting it
> > at all... If you do import Foo::bar you'll get an error if Bar is
> > already defined.
>  
>  I was supposed to suggest triggering a E_NOTICE that Bar is already
>  defined and instantiate the Bar class of "global". But if you want
>  something more radical... =)

Actually I was wrong - as of now AFAIK there's no error. The problem is 
when we import something we don't really know what it is - so we can't 
tell if it's bad. It might be legitimate to have class Foo and namespace 
imported as Foo. But we also may prohibit that just to avoid confusion.
I checked into CVS the initial rules which say how it's resolved and 
right now it'd be resolved to namespace, but I'm thinking about 
restricting it or at least putting a warning/notice there. Not decided yet.

>  Bad example I did. I was supposed to ask for namespace level
>  variables. Not in global scope, not in class scope. =)

Variables probably won't happen. Too much trouble and no real place to 
put them in. And no real need IMO - using globals in library context is 
A Bad Idea (TM) anyway. But constants may help since they may define 
some things like options, flags, limits, defaults, etc. Java solves it 
by packing constants into classes, but I am thinking requiring class for 
just a constant may be too much. So maybe we'd support namespaced constants.

>  I have another questions regarding namespace support... well, about
>  function support.
>  
>  1- How will is_a, instanceof, will behave in this situation?
>  
>  $a = new NS1::SubNS1::MyClass();
>  
>  echo is_a( $a, "MyClass" ); ????? true/false?

False.

>  echo is_a( $a, "NS1::SubNS1::MyClass" ); ???

True.

>  2- Will exist some namespace specific functions? Examples:
>  
>  $a = namespace_contains( "SomeClass" );

Not likely.

>  $b = namespace_exists( "NS1" );

Not likely either.

>  $c = is_a_namespace_class ( $NS1ObjString );

What's that supposed to do?

There might, however, exist an operator (name is just for demo purposes)

fullname("MyClass") which would produce NS1::SubNS1::MyClass - i.e. 
would resolve imports. Right now namespaces are purely compile-time so 
it would be compile-time operator. We might add runtime component to it 
if we see the necessity (necessity means good use cases, not "I'd like 
it because it sounds cool" ;) which would allow runtime resolution of 
names. That would somewhat complicate things though as each file would 
have to maintain separate import context at runtime.

-- 
Stanislav Malyshev, Zend Software Architect
stas@[...].com   http://www.zend.com/
(408)253-8829   MSN: stas@[...].com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php