Hi,
I read whole discussion and I'd like to share my opinion.
Similarly, allowing multiple namespaces per file does not limit the
developer in any way. Not allowing them does. I always thought a
language should be designed to empower it's developers, not get in
their way.My opinion is that sometimes language should "get in the way" - if the
developer is trying to do a wrong thing. Doing things right should be
easy, doing things wrong should be hard. I agree that this means we
should choose some definitions for right and wrong, and not everybody
would necessarily agree, but I think the benefit of the clearer program
structure exceeds the disadvantage of not being able to do some tricks.
That's one of the reasons why PHP doesn't have some things that other
languages might have, such as nested classes, multiple inheritance or
closures.
I agree with Andrew Minerd. Language shouldn't get in developers way.
If its too
hard to implement then let it be. Most developers can live with that I
guess. However if
the only reason for this is so called "clearer program structure" then
I don't think
this limit is reasonable. There's no such thing as absolutely "wrong
thing to do".
The thing that is "wrong thing to do" in one situation may be a "good
thing to do" in
other. One size does not fit all.
The other thing that bothers me is namespaces nesting. It was said
that namespaces
nesting is not supported. Then I'm missing a point in having namespace
named "A::B".
Lets say I have three files:
a.php:
<?php
namespace A;
function foo()
{
}
?>
b.php:
<?php
namespace A::B;
function bar()
{
//foo();
}
?>
index.php:
<?php
require 'a.php';
require 'b.php';
import A;
foo(); // should call A::foo(), right?
B::bar(); // will this call A::B::bar()?
?>
If this works then we have a nested namespace here. The only thing
that's missing is
[commented] foo() call in A::B::bar() to be correctly resolve to
A::foo() as now it would
resolve to built-in function foo() if I understand it correctly.
Now if this does not work then whats the point in having namespace
"A::B" instead of "A_B"? IMHO this brings more confusion then
clearness.
Regards,
Giedrius
The other thing that bothers me is namespaces nesting. It was said
that namespaces
nesting is not supported. Then I'm missing a point in having namespace
named "A::B".
The same reason some people write $a = f($z, $t) and some write
$parsed_template = template_parser($template, $data_values) :)
Lets say I have three files:
a.php:
<?php
namespace A;function foo()
{
}
?>b.php:
<?php
namespace A::B;function bar()
{
//foo();
}
?>index.php:
<?php
require 'a.php';
require 'b.php';import A;
foo(); // should call A::foo(), right?
B::bar(); // will this call A::B::bar()?
?>
import A is a no-op. You do import A::B and then you can do B::bar.
import N means "something that is named N can now be referred only by
it's 'last name' last(N), last name being last segment of the long
name". If you have short names, you don't need namespaces, but if you
have names like PEAR::DB::Record::Type::Modifier::Exception, you
probably do :)
Now if this does not work then whats the point in having namespace
"A::B" instead of "A_B"? IMHO this brings more confusion then
clearness.
The point is you can a) omit namespace prefix inside namespace and b)
use just B (or C if you wish) instead of A::B outside, once you did
import. As I said, with long names it makes sense, with short ones you
are OK without it.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
The other thing that bothers me is namespaces nesting. It was said
that namespaces
nesting is not supported. Then I'm missing a point in having namespace
named "A::B".The same reason some people write $a = f($z, $t) and some write
$parsed_template = template_parser($template, $data_values) :)
I wasn't talking about a short/long names :-)
I was talking about a separator inside a namespace name.
Lets say I have three files:
a.php:
<?php
namespace A;function foo()
{
}
?>b.php:
<?php
namespace A::B;function bar()
{
//foo();
}
?>index.php:
<?php
require 'a.php';
require 'b.php';import A;
foo(); // should call A::foo(), right?
B::bar(); // will this call A::B::bar()?
?>import A is a no-op. You do import A::B and then you can do B::bar.
import N means "something that is named N can now be referred only by
it's 'last name' last(N), last name being last segment of the long
name". If you have short names, you don't need namespaces, but if you
have names like PEAR::DB::Record::Type::Modifier::Exception, you
probably do :)Now if this does not work then whats the point in having namespace
"A::B" instead of "A_B"? IMHO this brings more confusion then
clearness.The point is you can a) omit namespace prefix inside namespace and b)
use just B (or C if you wish) instead of A::B outside, once you did
import. As I said, with long names it makes sense, with short ones you
are OK without it.
a) I was talking about namespace name "A_B" not class/function name.
b) So as far as I understand "import" doesn't actually import names
from specified
namespace to the current one but just renames long namespace name to a
shorter one. And if I get it right the separator in the namespace name
is allowed
and required only to express default name when importing without "as".
Am I right?
Regards,
Giedrius
a) I was talking about namespace name "A_B" not class/function name.
_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm rather reluctant to start the "my separator is
better than yours" thread for the 42th time :)
b) So as far as I understand "import" doesn't actually import names
from specified
namespace to the current one but just renames long namespace name to a
shorter one. And if I get it right the separator in the namespace name
is allowed
and required only to express default name when importing without "as".
Am I right?
Not exactly. It does import, but not names just one name - the very same
name it has as an argument. The :: is used to join components of the
name. Note that you can also do:
import Foo::XML as myXML;
$a = new myXML::Data::Document();
if you wish so.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
a) I was talking about namespace name "A_B" not class/function name.
_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm rather reluctant to start the "my separator is
better than yours" thread for the 42th time :)
Me neither :-) :: is perfectly good for me. I just missed the point of
having it more
then once if it's only purpose is to separate default short name part
from whole
name.
b) So as far as I understand "import" doesn't actually import names
from specified
namespace to the current one but just renames long namespace name to a
shorter one. And if I get it right the separator in the namespace name
is allowed
and required only to express default name when importing without "as".
Am I right?Not exactly. It does import, but not names just one name - the very same
name it has as an argument. The :: is used to join components of the
name. Note that you can also do:import Foo::XML as myXML;
$a = new myXML::Data::Document();
Now that explains a lot :-) If I get it right I can have namespaces
A::B::C and A::B::D
then create an alias for A::B with "import A::B" and use B::C::foo()
and B::D::foo() in
that file. Thats nice. Looks like namespace nesting though it isn't :-)
Regards,
Giedrius