Rasmus Lerdorf wrote:

Sheez, guys, slow down a tad. Just because he says "no performance
penalty" in the description, doesn't make it true. Unless I missed
something in the patch, I don't see how I would resolve the symbols at
compile-time now which means it has been moved to the executor and in
doing so it implies a huge performance penalty.

Hi Rasmus,

I'm actually certain that the patch doesn't change any of the symbol
resolution logic or add any need to move things from the compile-time to
the executor. This is because the namespace implementation basically
works more like a #define macro to auto-prepend class names and function
names with namespace names.

Old logic:

request start => CG(namespace) = NULL T_NAMESPACE ...;
zend_do_namespace() => defines CG(namespace) which is used for creating
class and function entries
php junk
compile end => if (CG(namespace)) destruct CG(namespace), CG(namespace)
= NULL

New logic:

request start => CG(namespace) = NULL
[potential php junk]
T_NAMESPACE ... {
zend_do_namespace() => defines CG(namespace) which is used for creating
class and function entries
php junk
}
zend_do_end_namespace() => destruct CG(namespace), CG(namespace) = NULL
php junk (which can include class/function entries, although that's a
terrible idea)
T_NAMESPACE ... {
zend_do_namespace() => defines CG(namespace) which is used for creating
class and function entries
php junk
}
zend_do_end_namespace() => destruct CG(namespace), CG(namespace) = NULL
compile end => if (CG(namespace)) destruct CG(namespace), CG(namespace)
= NULL

In other words, the only difference is that mid-parse the namespace
#define-like prefix can be modified or removed.

Greg

I think there should be just one way to designate a namespace, not
two different ones with different behaviors.

David

Am 21.08.2007 um 21:09 schrieb Gregory Beaver:

Stanislav Malyshev wrote:

What happens if you mix them?
<?php namespace baz;

namespace foo {
class Bar {
...
}
}
?>

That's not the fun yet. This is:

<?php
namespace baz;

namespace foo { ...whatever... }

class bar {}

?>

If by fun you mean "Fatal error: Namespace cannot be declared twice
(without brackets) or nested within brackets in ..."

To clarify, the patch works as follows:

when namespace baz; is encountered, CG(current_namespace) is set to a
non-NULL zstr (name->u.constant). Later on, when you try to namespace
foo {}, this check fails:

if (CG(current_namespace)) {
zend_error(E_COMPILE_ERROR, "Namespace cannot be declared twice
(without brackets) or nested within brackets");
}

In other words, if there is a current namespace present, you can't
declare another or redeclare. This code also fails with the same
E_COMPILE_ERROR above (and is one of the new tests in the patch):

<?php
namespace baz;
namespace foo;

class bar {}
?>

Now, is bar in namespace baz or not? I guess it is, otherwise it
stops
making any sense. So now when you see in the code it says "class bar"
what do you do to know which namespace it is? Right, you go up to the
code, counting closing and open brackets and hoping you didn't
miss any
and try to figure out if it's that main namespace or one of the other
ones. Now next question - how ones in namespace foo are supposed
to call
class bar? They'd have to call it by full name, baz::bar, right?
Welcome
back, long names. But wait, we could use an import, right? So now
we'd
have block-local imports. And we'd have to track them per
namespace-block. BTW, what about imports in baz - are they active in
foo? What if baz wants to talk to class in foo - should it import it?
And BTW - how the patch solves it - I didn't read all of it, but not
sure it does it correctly.

Would the compiler have a heart attack if someone did:

<?php
namespace foo {
namespace baz {
class Bar { ... }
}
}
?>

This syntax implies that baz has access to names in foo. The separate
syntax doesn't. But that's only part of the story - remember the
names/imports story above? Now take that and make it unlimited depth
stack, since you'd have to track everything on each nesting level
separately. I wouldn't want to open this can of worms. That'd produce
messy engine and messy code.

I don't want to open this can of worms either, and so I didn't. :)

Greg

<?php
namespace baz;

namespace foo { ...whatever... }

class bar {}

?>

If by fun you mean "Fatal error: Namespace cannot be declared twice
(without brackets) or nested within brackets in ..."

Ah, I didn't read it good enough - was under impression mixing them was
allowed.

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

Hi,

I'll try to answer some of the questions I saw here based on Gregory's
patch and I will ask for more information about external things that I
probably misunderstood.

And nested namespaces really make a mess of this if something like this
is allowed:

foo.inc:
namespace A {
include 'bar.inc';
}

bar.inc:
namespace B {
...
}

This is not currently allowed.
There are still a limitation of nested namespaces.

<?php
namespace baz;

namespace foo {
class Bar {
...
}
}
?>

It's the same as the previous situation. You have a current namespace
scope, so it'll raise an error.

Would the compiler have a heart attack if someone did:

<?php
namespace foo {
namespace baz {
class Bar { ... }
}
}
?>

It'll only throw this error: "Namespace cannot be defined twice
(without brackets) or nested within brackets"

<?php
namespace baz;

namespace foo { ...whatever... }

class bar {}

?>

Now, is bar in namespace baz or not?

No, there is a syntax error. And you'll receive the same message I
showed before.

Also this change is inconsistent with renaming "namespace" to "package".

Exactly. I am interested to see namespace support in PHP too, but the
current implementation tell me the contrary. Gregory purposed a patch
to remove one of the PHP namespace limitation. =)

AFAIK, this patch do not have performance impact. It only tries to add
another way to define namespaces. So it's like the original
implementation, but it holds the current_namespace based in the
current scope (old behavior was the entire file, not it's either the
entire file OR the namespace block (both are disallowed)).

I don't understand very well what Rasmus tried to mention with nested
namespaces and opcache, but seems there're a limitation and I am
interested to know which (if possible, try to explain in other
words)... =)
Why am I asking this? I am changing the Gregory's patch... now,
current_namespace holds a zval. I am changing it first to a stack, and
pushing and popping the namespaces based on block declaration. So, the
piece of code Stanislav pointed before:

namespace Foo;

namespace Bar { class Test {} }

class Test {}

Is being resolved as Foo::Bar::Test and Foo::Test.
BUT... it's not working as expected yet. Currently it's defining as:
Foo::Test and Bar::Test. This is my first try to do something
internally in PHP, so I'm having huge headaches to modify the source.
My first try to avoid this:

namespace Long::Nspace::Declaration::In:The::TopOf::TheFile;

class Foo {}

To something more clean and organized, like:

namespace Logn {
namespace Nspace {
...
}
}

I know there're a lot of other impacts by doing this, but since this
is a draft yet, it can be implemented more and more functionalities,
like Inner Namespace able to use parent definitions. But this is just
a beginning.

Also, mentioning the Rasmus piece of code:

foo.inc:
namespace A {
include 'bar.inc';
}

bar.inc:
namespace B {
...
}

I don't know how do you control it internally, but as long as this is
the only call in the entire script, the right scope should be: A::B,
and not B. If I include bar.inc outside any namespace scope, then it
should be B.

Waiting a response...

Best regards,

Hello Dmitry,

LOL!!!!!

climbing up the chair again, this is the most stupiest argument ever.

Could you please keep the attitude down? Calling names is not going to
help anything.

didn't you just yesterday suggest we keep it namespace anyway until we
are done. And didn't you guys say that we might end up with something that
really is namespaces anyway.

Please guyse read your own arguments if you do not manage to remember them.

We discuss and consider a lot of options. Including ones that
contradict. That's the meaning of discussion - to consider all options
and find out the best. Dmitry was absolutely right to note that naming
can wait until we finalize all the concept, and that braces support
namespace naming. Though, they create many other problems, which we need
to have addressed before we could consider adding it to the concept.

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

--

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil

Stanislav Malyshev wrote:

that if you try to "combine" two files that contain import statements,
it will be necessary to expand the imports. Fortunately, since

What do you mean by "expand"?

import allows aliasing specific namespaced files and classes within a
file. For example:

But import has nothing to do with files. import works on names, not files.
s/files/functions/ I mis-typed and didn't notice, sorry.

<?php
namespace foo {
class bar {}
}
import foo::bar;
namespace gronk {
class bar {}
}
?>

Fatal error: Class name 'bar' coflicts with import name

Ouch! So I can't actually combine namespaces from different areas -
how I'm supposed to know when I write "gronk" that somebody is going
to stick this code into the context that already has the name "bar" in
it? It's exactly the problem namespaces are meant to solve! Moreover,
if you take two files with working code and copy-paste them into one
file, they have a lot of chance of stopping working. If this isn't
confusion, I don't know what is.
Careful Stas :), you probably missed the "import foo::bar;" This code
works just fine:

<?php
namespace foo {
class bar {}
}
namespace gronk {
class bar {}
}
?>

No fatal errors, everybody is happy. The problem is importing the "bar"
identifier. This code also fails with the same fatal error for the same
reason:

file1.php:
<?php
namespace foo;
class bar {}
?>

file2.php:
<?php
namespace gronk;
import foo::bar;
class bar {}
?>

That will clear up any possible confusion.

No, on the contrary - it would create a lot of confusion, since now
you can break namespaced code with code outside namespace, which
wasn't supposed to happen by definition.

It still doesn't. As I pointed out above, the same error is possible
with the current implementation pre-my patch.

Well it kind of makes namespaces behave more like namespaces, don't you

Please stop this "only C++ implementation is right" thing.
I don't care about C++. I'm only talking about the patch I proposed.

Thanks,
Greg