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
[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
