# solving the namespace conflict issues between function/static method class constant/ns constant

- Thread: https://externals.io/message/40569
- Original archive: https://news-web.php.net/php.internals/40569
- Started by Greg Beaver on 2008-09-20T03:59:46+00:00
- Messages: 32
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/40569.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #40569 — Greg Beaver — 2008-09-20T03:59:46+00:00

URL: https://externals.io/message/40569#40569

Hi all,

There is a problem in the namespace implementation.  This code 
demonstrates the issue:

code.inc:
<?php
namespace foo;
class test {
const my = 1;
static function bar(){}
}

namespace foo::test;
const my = 2;
function bar(){}
?>

main.php:
<?php
include 'code.inc';
foo::test::bar(); // always calls namespace function
call_user_func(array('foo::test', 'bar')); // the only way to call 
static method
echo foo::test::my; // always 2
$a = new foo::test;
echo $a::my; // the only way to access foo::test::my
?>

There are 5 ways to solve this:

1) document it and hope no one uses it [this is the current strategy, 
minus the documentation part]
2) add a fatal error on conflicting names.

http://pear.php.net/~greg/ns_method.func.conflict.patch.txt

Unfortunately, this can only work for methods/functions, as namespace 
constants are actually defined at run-time, and so conflicts can't be 
detected until then, which does not provide any benefit (you want to 
catch this conflict at compile-time).

3) create a disambiguation method.

http://pear.php.net/~greg/ns.func_const.patch.txt

This introduces function:: and const:: as prefixes to disambiguate.

<?php
function::foo::test::bar(); // always calls namespace function
foo::test::bar(); // always calls static method if defined, falls back 
to ns function if not
const::foo::test::my; // namespace constant
foo::test::my; // class constant
?>

The drawback of this approach is that "foo::test::bar" will always look 
for class "foo::test", which means if autoload is defined, it will be 
called for all non-prefixed function calls.  Unfortunately, the only 
other keyword for disambiguating would be "class::" as in 
"class::foo::test::bar()" but this is excessively confusing.

4) remove functions/constants from namespaces
5) a simply syntax change to namespaces, introducing a new concept: 
namespace element.

A namespace element is a class, function or constant defined within a 
namespace declaration:

<?php
namespace foo;
class bar {} // class element bar in namespace foo
function bar(){} // function element bar in namespace foo
const bar=1; // const element bar in namespace foo
?>

This is similar to class elements:

<?php
class foo {
function bar(){} // method element bar in class foo
const bar=1; // constant element bar in class foo
public $bar=1; // variable element bar in class foo
}
?>

Currently, this code:

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

creates a class named "foo::bar::buh", essentially joining the namespace 
"foo::bar" and its class element "buh" with the separator "::".  This 
turns out to be the root of the problem with the conflicts between class 
elements and namespace elements.  The last patch introduces a new 
namespace element operator to delineate the boundary between namespace 
name and element name.  For the patch, I recycled `T_OBJECT_OPERATOR` (->).

current way:
<?php
foo::bar->test(); // namespace foo::bar, call to function element test()
foo->bar::test(); // namespace foo, call to static method element test() 
in class element bar
foo->myconst; // namespace foo constant myconst
foo::myconst; // class foo constant myconst
?>

The patch is at:

http://pear.php.net/~greg/ns.element.patch.txt

This is the most extensive change.  The patch preserves :: as global 
element accessor (::strlen() calls strlen internal function, for 
instance).  I'm happy to answer any other questions.

So, these are the choices.  I suggest we all take a rational look at the 
options, and understand the consequences of each, and make the best 
choice possible.

Thanks,
Greg

---

## #40574 — Etienne Kneuss — 2008-09-20T16:24:31+00:00

URL: https://externals.io/message/40569#40574 · In reply to: #40569

Hello,


> Hi all,
>
> There is a problem in the namespace implementation.  This code demonstrates
> the issue:
>
> code.inc:
> <?php
> namespace foo;
> class test {
> const my = 1;
> static function bar(){}
> }
>
> namespace foo::test;
> const my = 2;
> function bar(){}
> ?>
>
> main.php:
> <?php
> include 'code.inc';
> foo::test::bar(); // always calls namespace function
> call_user_func(array('foo::test', 'bar')); // the only way to call static
> method
> echo foo::test::my; // always 2
> $a = new foo::test;
> echo $a::my; // the only way to access foo::test::my
> ?>
>
> There are 5 ways to solve this:
>
> 1) document it and hope no one uses it [this is the current strategy, minus
> the documentation part]
> 2) add a fatal error on conflicting names.
>
> http://pear.php.net/~greg/ns_method.func.conflict.patch.txt
>
> Unfortunately, this can only work for methods/functions, as namespace
> constants are actually defined at run-time, and so conflicts can't be
> detected until then, which does not provide any benefit (you want to catch
> this conflict at compile-time).
>
> 3) create a disambiguation method.
>
> http://pear.php.net/~greg/ns.func_const.patch.txt
>
> This introduces function:: and const:: as prefixes to disambiguate.
>
> <?php
> function::foo::test::bar(); // always calls namespace function
> foo::test::bar(); // always calls static method if defined, falls back to ns
> function if not
> const::foo::test::my; // namespace constant
> foo::test::my; // class constant
> ?>
>
> The drawback of this approach is that "foo::test::bar" will always look for
> class "foo::test", which means if autoload is defined, it will be called for
> all non-prefixed function calls.  Unfortunately, the only other keyword for
> disambiguating would be "class::" as in "class::foo::test::bar()" but this
> is excessively confusing.
>
> 4) remove functions/constants from namespaces
> 5) a simply syntax change to namespaces, introducing a new concept:
> namespace element.
>
> A namespace element is a class, function or constant defined within a
> namespace declaration:
>
> <?php
> namespace foo;
> class bar {} // class element bar in namespace foo
> function bar(){} // function element bar in namespace foo
> const bar=1; // const element bar in namespace foo
> ?>
>
> This is similar to class elements:
>
> <?php
> class foo {
> function bar(){} // method element bar in class foo
> const bar=1; // constant element bar in class foo
> public $bar=1; // variable element bar in class foo
> }
> ?>
>
> Currently, this code:
>
> <?php
> namespace foo::bar;
> class buh{}
> ?>
>
> creates a class named "foo::bar::buh", essentially joining the namespace
> "foo::bar" and its class element "buh" with the separator "::".  This turns
> out to be the root of the problem with the conflicts between class elements
> and namespace elements.  The last patch introduces a new namespace element
> operator to delineate the boundary between namespace name and element name.
>  For the patch, I recycled `T_OBJECT_OPERATOR` (->).
>
> current way:
> <?php
> foo::bar->test(); // namespace foo::bar, call to function element test()
> foo->bar::test(); // namespace foo, call to static method element test() in
> class element bar
> foo->myconst; // namespace foo constant myconst
> foo::myconst; // class foo constant myconst
> ?>
>
> The patch is at:
>
> http://pear.php.net/~greg/ns.element.patch.txt
>
> This is the most extensive change.  The patch preserves :: as global element
> accessor (::strlen() calls strlen internal function, for instance).  I'm
> happy to answer any other questions.
>
> So, these are the choices.  I suggest we all take a rational look at the
> options, and understand the consequences of each, and make the best choice
> possible.
>
> Thanks,
> Greg

Good work, but I (and I'm probably not alone) can't really keep up
with all those namespace threads and proposals for changes and
resolution fixes and this and that,so :

Please use our nice RFC system!

Regards

-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal

---

## #40583 — Richard Quadling — 2008-09-20T23:43:41+00:00

URL: https://externals.io/message/40569#40583 · In reply to: #40574

2008/9/20 Etienne Kneuss <colder@php.net>:
> Hello,
>
> 
> > […]
>
> Good work, but I (and I'm probably not alone) can't really keep up
> with all those namespace threads and proposals for changes and
> resolution fixes and this and that,so :
>
> Please use our nice RFC system!
>
> Regards
>
> --
> Etienne Kneuss
> http://www.colder.ch
>
> Men never do evil so completely and cheerfully as
> when they do it from a religious conviction.
> -- Pascal
>
> --
> 
> 
>
>

How feasible would it be to use # as the namespace separator. I know #
is used for comments, but with /* */ and // that all seems covered.

namespace#function() vs class::static()

Seems like a winner. Just a whole ton of BC though for those using #
for comments.

Regards,

Richard.

-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

---

## #40584 — Steph Fox — 2008-09-20T23:57:51+00:00

URL: https://externals.io/message/40569#40584 · In reply to: #40583

> Seems like a winner. Just a whole ton of BC though for those using #
> for comments.

Yep, so forget it. Or were you doing a Jani? ;)

- Steph

---

## #40585 — Diego Feitosa — 2008-09-21T00:23:57+00:00

URL: https://externals.io/message/40569#40585 · In reply to: #40584

I can't see how this can break existing code... '#' is usually used at the
beginning of a line or after ';'

<?php
# comment
$foo = "bar"; # comment $_this->will->not->be->evaluated()
?>

Regards,



> Seems like a winner. Just a whole ton of BC though for those using #
> > […]
>
> Yep, so forget it. Or were you doing a Jani? ;)
>
> - Steph
>
>
> --
> 
> 
>
>


-- 
Diego Feitosa
www.dnfeitosa.com

Caelum - Ensino e Soluções em Java
diego.feitosa@caelum.com.br
www.caelum.com.br

---

## #40586 — Jochem Maas — 2008-09-21T00:25:27+00:00

URL: https://externals.io/message/40569#40586 · In reply to: #40584

Steph Fox schreef:
> > […]
> 
> Yep, so forget it. Or were you doing a Jani? ;)

It seems to hav escaped everyone that Greg's latest proposal doesn't change
the namespace seperator token, instead it comes with a new concept of namespace
member [token].

ambiguity related to the 'use' statements remains regardless of what the namespace
seperator is ... therefore the proposal for a new operator that allows to explicitly
reference namespace members:

<?php

use my#funky#namespace#strlen; // is this aliasing a class, function or namespace?

 `strlen()`; // is this interal `strlen()` or namespaced function?

?>

and obviously BC dictates that '#' cannot be considered, but that's moot anyhow.


> - Steph

---

## #40587 — Steph Fox — 2008-09-21T00:36:28+00:00

URL: https://externals.io/message/40569#40587 · In reply to: #40586

Hi Jochem,

> It seems to hav escaped everyone that Greg's latest proposal doesn't 
> change
> the namespace seperator token, instead it comes with a new concept of 
> namespace
> member [token].

No, that didn't escape me at all. I was responding to the OP.

To be clear, I have worked with Greg. The experience left me with large 
amounts of respect for his creativity and analytical abilities. They exceed 
mine by a number of quadzillions.

That doesn't mean Greg's always in the right, but it does mean he's always 
worth hearing. I know for sure I'm not the only person on this list who sees 
him that way, and most of the others have far more influence than I do.

Next time, perhaps you and I should both let sleeping dogs lie ;)

- Steph

---

## #40588 — Larry Garfield — 2008-09-21T01:00:38+00:00

URL: https://externals.io/message/40569#40588 · In reply to: #40583

On Saturday 20 September 2008 6:43:41 pm Richard Quadling wrote:

> > […]
>
> How feasible would it be to use # as the namespace separator. I know #
> is used for comments, but with /* */ and // that all seems covered.
>
> namespace#function() vs class::static()
>
> Seems like a winner. Just a whole ton of BC though for those using #
> for comments.

I agree that #5 seems like the best solution.  The problem is caused by the 
double meaning of ::.  All of the other solutions feel like bandaids.  

Of course, the problem then is finding a symbol that is not already used.  I 
don't think reusing -> is any wiser than reusing ::.  # would be great if it 
wasn't already in use, but that sort of change is really not appropriate for 
5.3.  What other symbols are available or could be created?  (::: has been 
suggested and would give the opportunity to introduce more Hebrew into the 
language parser...)

-- 
Larry Garfield
larry@garfieldtech.com

---

## #40589 — Gregory Beaver — 2008-09-21T03:36:49+00:00

URL: https://externals.io/message/40569#40589 · In reply to: #40588

Larry Garfield wrote:
> On Saturday 20 September 2008 6:43:41 pm Richard Quadling wrote:
> 
> > […]

[snip]

> I agree that #5 seems like the best solution.  The problem is caused by the 
> double meaning of ::.  All of the other solutions feel like bandaids.  
> 
> Of course, the problem then is finding a symbol that is not already used.  I 
> don't think reusing -> is any wiser than reusing ::.  # would be great if it 

Let's be clear.  Here is a sample of code with the new syntax:

<?php
namespace name::still::has::double::colon;
const oscopy = 1;
class blow{
const byblow = 1;
static function hard(){}
}

namespace another::name;
use name::still::has::double::colon;

// fully qualified name:
// note that -> is only used once
// to specify the boundary between namespace name and namespace member.
$a = new name::still::has::double::colon->blow;
$a = new colon->blow;
// static method call
colon->blow::hard();
// or
name::still::has::double::colon->blow::hard();

// ns constant
echo colon->oscopy;

namespace blow;
function hard(){}

namespace a::third::name;
// demonstrate importing a class name
// which is different from importing a namespace name
use name::still::has::double::colon->blow;

// class static method
blow::hard();
// namespace function
::blow->hard();
// class constant
echo blow::byblow;
?>

Two important things to note:
 - ambiguity between namespace name and class name is eliminated
<?php
namespace foo;
class test{
}
namespace foo::test;
class test{}
namespace third;
use foo::test;
$a = new test;  // this is namespace foo, class test
$a = new test::test; // this is namespace foo::test, class test
?>
 - this separator is self-documenting.  One does not need to grep source
code to determine whether blah->thing is a namespaced function or a
static method of class blah.  The same is true of use statements.  It is
crystal clear whether we are importing a namespace or a class name.
This will make debugging someone else's code a lot easier than it
otherwise would be.

Jochem has informed me he is taking care of the wiki RFC for this stuff.
 I am allergic to wikis, unfortunately.

Thanks,
Greg

---

## #40590 — Lupus Michaelis — 2008-09-21T06:13:02+00:00

URL: https://externals.io/message/40569#40590 · In reply to: #40588

Larry Garfield a écrit :

> I agree that #5 seems like the best solution.  The problem is caused by the 
> double meaning of ::.  All of the other solutions feel like bandaids.  


   They are not a double meaning : it is a scope resolver. Like in C++. 
So please all stop this war about namespaces, and look where it was 
resolved in other languages. It will be wisely :)

-- 
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

---

## #40591 — Lupus Michaelis — 2008-09-21T07:43:39+00:00

URL: https://externals.io/message/40569#40591 · In reply to: #40590

Lupus Michaelis a écrit :
> look where it was resolved in other languages. 

   I mean « how » and not « where », of course, sorry :-/

-- 
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

---

## #40592 — Jochem Maas — 2008-09-21T08:05:41+00:00

URL: https://externals.io/message/40569#40592 · In reply to: #40587

Steph Fox schreef:
> Hi Jochem,
> 
> > […]
> 
> No, that didn't escape me at all. 

oh, good!

> I was responding to the OP.
> 
> To be clear, I have worked with Greg. The experience left me with large 
> amounts of respect for his creativity and analytical abilities. They 
> exceed mine by a number of quadzillions.

I've been conversing with him over the last couple of weeks regarding namespaces
off-list and have every reason to second that thought.

> 
> That doesn't mean Greg's always in the right, but it does mean he's 
> always worth hearing. I know for sure I'm not the only person on this 
> list who sees him that way, and most of the others have far more 
> influence than I do.

which makes it all the more sad that the only person taking a real interest
in his [latest namespace] proposal is the one person who's completely
adamant that there is nothing in the current namespace implementation that
needs addressing (all issues come down to 'your using it wrong')

> Next time, perhaps you and I should both let sleeping dogs lie ;)

I don't get the use of that idiom in this context. I think the 'namespace' dog
has been up and about for a while already, granted some would like to see it
put down permanently :-)

> 
> - Steph

---

## #40593 — Greg Beaver — 2008-09-21T14:59:44+00:00

URL: https://externals.io/message/40569#40593 · In reply to: #40590

Lupus Michaelis wrote:
> Larry Garfield a écrit :
> 
> > […]
> 
> 
>   They are not a double meaning : it is a scope resolver. Like in C++.
> So please all stop this war about namespaces, and look where it was
> resolved in other languages. It will be wisely :)

Hi,

Amazingly enough, this work has already been done.  The first thing
noticed is that C++ is a compiling language, and PHP isn't.  Therefore
at compile time, it is possible to know every single file that will be
available, every single class, and so on.  This enables all kinds of
clever resolution such as importing ns::* and it actually works with
full performance.

PHP, on the other hand, is a dynamic language, and it is impossible to
know in advance which files, which classes, which namespaces will be
defined.  Other dynamic languages that have implemented namespaces have
solved the problems mentioned via run-time resolution, which is much slower.

One key difference from C++ is that namespaces do *not* define scope in
PHP.  The only constructs that define scope different from global scope
are functions and now closures (as I understand them from reading the
mailing list).

I suppose I should have mentioned option #6: do all class, function and
constant resolution at run-time, "obsoleting" all opcode caches and make
PHP 5.3 an unusable release for any high traffic websites.

Greg

---

## #40596 — Dmitry Stogov — 2008-09-22T12:58:26+00:00

URL: https://externals.io/message/40569#40596 · In reply to: #40593

Hi Greg,

Greg Beaver wrote:
> Lupus Michaelis wrote:
> > […]
> 
> Hi,
> 
> Amazingly enough, this work has already been done.  The first thing
> noticed is that C++ is a compiling language, and PHP isn't.  Therefore
> at compile time, it is possible to know every single file that will be
> available, every single class, and so on.  This enables all kinds of
> clever resolution such as importing ns::* and it actually works with
> full performance.
> 
> PHP, on the other hand, is a dynamic language, and it is impossible to
> know in advance which files, which classes, which namespaces will be
> defined.  Other dynamic languages that have implemented namespaces have
> solved the problems mentioned via run-time resolution, which is much slower.
> 
> One key difference from C++ is that namespaces do *not* define scope in
> PHP.  The only constructs that define scope different from global scope
> are functions and now closures (as I understand them from reading the
> mailing list).
> 
> I suppose I should have mentioned option #6: do all class, function and
> constant resolution at run-time, "obsoleting" all opcode caches and make
> PHP 5.3 an unusable release for any high traffic websites.

Please check your suggestions before publishing them.

<?php
class Foo {
        function bar() {
        }
}

function simplecall() {
  for ($i = 0; $i < 1000000; $i++) {
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
      Foo::bar();
  }
}

simplecall();
?>

$ time php5.2/CGI-RELEASE/sapi/cli/php -n bench.php

real    0m7.458s
user    0m7.416s
sys     0m0.007s

$ time php5.3/CGI-RELEASE/sapi/cli/php -n bench.php

real    0m7.337s
user    0m7.252s
sys     0m0.002s


As you can see 5.3 is faster.
Of course it could be faster, but it's a winer anyway :)

I really don't see a reason to change namespace syntax into a less
intuitive way. Your speed degradation argument isn't truth. The
ambiguity problem exists, but it is just an ability to use php in a
wrong way. Just don't create conflicting names.

I would recommend option #1 (stay it as is + document)

Thanks. Dmitry.

---

## #40597 — Jochem Maas — 2008-09-22T13:20:29+00:00

URL: https://externals.io/message/40569#40597 · In reply to: #40596

Dmitry Stogov schreef:
> Hi Greg,
> 
> Greg Beaver wrote:

...

> 
> I really don't see a reason to change namespace syntax into a less
> intuitive way. 

I don't think the current implementation is intuitive, the ambiguity issues,
(and possibly the name resolution order, although I can't grok what the current
state of that is) are rather large WTFs.

> Your speed degradation argument isn't truth. The
> ambiguity problem exists, but it is just an ability to use php in a
> wrong way. Just don't create conflicting names.

which begs the question, what was namespaces created for?
(that's a serious question because your statement has me truly confused)

we can "Just not create conflicting names" without namespaces and
Stas has mentioned numerous times that namespace were not designed
just to avoid having to repeatedly type long symbol names.

another thing, the ability to use php the wrong way is an argument
that has been used lately both to:

1. advocate leaving functionality as it is and putting the
burden of responsibility on the developer to do the right thing.

2. advocate changing functionality (or making the functionality illegal)
in order to protect the user from doing something stupid.

.. not exactly consistent.

BTW, not creating conflicting names doesn't make the problem
completely dissappear, code is still vulnerable breakage due to
addition of new functions or classes in future version of the
engine.


> I would recommend option #1 (stay it as is + document)

It would seem that it's yours' and Stas' responsibility to
properly document how namespaces should be used because everyone
else either doesn't care much about it or has, according to you,
completely the wrong end of the stick with regard to the how/why/what
of namespaces.

Can we at least count on you [both] to provide that documentation?

---

## #40598 — Gregory Beaver — 2008-09-22T14:01:00+00:00

URL: https://externals.io/message/40569#40598 · In reply to: #40596

Dmitry Stogov wrote:
> Hi Greg,
>
> Greg Beaver wrote:
>   
> > […]
>
> Please check your suggestions before publishing them.
>
> <?php
> class Foo {
>         function bar() {
>         }
> }
>
> function simplecall() {
>   for ($i = 0; $i < 1000000; $i++) {
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>       Foo::bar();
>   }
> }
>
> simplecall();
> ?>

<snip>

hi Dmitry,

Let me quote myself from right above your reply:

"option #6: do all class, function and constant resolution at run-time"

This would be slow and eliminate most of the benefit of opcode caches. 
The script you posted does not demonstrate option #6 because that's not
how PHP works or has ever worked.  Which suggestion are you trying to
debunk?

I was never saying the current implementation is slow, only that it is
broken.  Without changes, it is dangerous in PHP's namespace
implementation to

1) ever use short names inside a namespace declaration for any class in
the same namespace not defined in the same file
2) mix functions and classes in the same project with hierarchical
namespace declarations, or mix namespace constants with class constants

#1 makes namespaces essentially more verbose than the existing situation
(:: is longer than _), and #2 requires users to perform more diligence
than they would have to before namespaces.  In both cases, this either
introduces more chance for subtle logic failure compared to PHP prior to
namespaces, or requires longer class names.  I highly doubt that is the
intention.

Returning to the original debate, if you really believe this conflict is
not an issue, then why was the first user note published last December a
note about this conflict?

http://us3.php.net/manual/en/language.namespaces.php#80035

Greg

---

## #40599 — Dmitry Stogov — 2008-09-22T14:03:52+00:00

URL: https://externals.io/message/40569#40599 · In reply to: #40597

Hi Jochem,

Jochem Maas wrote:
> Dmitry Stogov schreef:
> > […]
> 
> ...
> 
> > […]
> 
> I don't think the current implementation is intuitive, the ambiguity
> issues,
> (and possibly the name resolution order, although I can't grok what the
> current
> state of that is) are rather large WTFs.
> 
> > […]
> 
> which begs the question, what was namespaces created for?
> (that's a serious question because your statement has me truly confused)
> 
> we can "Just not create conflicting names" without namespaces and
> Stas has mentioned numerous times that namespace were not designed
> just to avoid having to repeatedly type long symbol names.
> 
> another thing, the ability to use php the wrong way is an argument
> that has been used lately both to:
> 
> 1. advocate leaving functionality as it is and putting the
> burden of responsibility on the developer to do the right thing.
> 
> 2. advocate changing functionality (or making the functionality illegal)
> in order to protect the user from doing something stupid.
> 
> .. not exactly consistent.
> 
> BTW, not creating conflicting names doesn't make the problem
> completely dissappear, code is still vulnerable breakage due to
> addition of new functions or classes in future version of the
> engine.

Right. Any touch of code can break something :)

Personally, I don't like inconsistencies and I would remove them if
possible. It wouldn't be a problem if PHP language was designed to
support namespaces, but it wasn't. Now we have to support backward
compatibility and provide new features without speed degradation and to
do it sometimes we have to make compromises because absolutely
consistent decisions are not possible in real life.

> 
> > […]
> 
> It would seem that it's yours' and Stas' responsibility to
> properly document how namespaces should be used because everyone
> else either doesn't care much about it or has, according to you,
> completely the wrong end of the stick with regard to the how/why/what
> of namespaces.
> 
> Can we at least count on you [both] to provide that documentation?

README.namespaces was committed into PHP_5_3 about year ago.

Thanks. Dmitry.

---

## #40600 — Dmitry Stogov — 2008-09-22T14:37:34+00:00

URL: https://externals.io/message/40569#40600 · In reply to: #40598

Gregory Beaver wrote:
> Dmitry Stogov wrote:
> > […]
> 
> <snip>
> 
> hi Dmitry,
> 
> Let me quote myself from right above your reply:
> 
> "option #6: do all class, function and constant resolution at run-time"
> 
> This would be slow and eliminate most of the benefit of opcode caches. 
> The script you posted does not demonstrate option #6 because that's not
> how PHP works or has ever worked.

The script I posted calls static methods and does two cache lookups in
5.3 because of runtime resolution. However it does quick cache lookups
without cache-value calculating. As you can see they work faster then
single hash lookup in 5.2.

>  Which suggestion are you trying to debunk?

Sorry, I probably misunderstood you, I thought you had talked about
speed of current implementation. Anyway, php resolves names at run-time now.

> I was never saying the current implementation is slow, only that it is
> broken.  Without changes, it is dangerous in PHP's namespace
> implementation to

I wouldn't say it broken, I would say it has some ambiguity problems.

> 1) ever use short names inside a namespace declaration for any class in
> the same namespace not defined in the same file

why is it dangerous?

> 2) mix functions and classes in the same project with hierarchical
> namespace declarations, or mix namespace constants with class constants
> 
> #1 makes namespaces essentially more verbose than the existing situation
> (:: is longer than _), and #2 requires users to perform more diligence
> than they would have to before namespaces.  In both cases, this either
> introduces more chance for subtle logic failure compared to PHP prior to
> namespaces, or requires longer class names.  I highly doubt that is the
> intention.
> 
> Returning to the original debate, if you really believe this conflict is
> not an issue, then why was the first user note published last December a
> note about this conflict?
> 
> http://us3.php.net/manual/en/language.namespaces.php#80035

I could add nothing. The problem exists, but proposed solution make
language even worse. Having A::B->foo() and ->foo() or ::foo() and
A::B->C::foo() is much more inconsistent from my point of view.
It would be better to change static class separator from :: to ->, but
it's a BC break

Thanks. Dmitry.

---

## #40601 — Lukas Kahwe Smith — 2008-09-22T15:45:33+00:00

URL: https://externals.io/message/40569#40601 · In reply to: #40600

> > […]
>
> I could add nothing. The problem exists, but proposed solution make
> language even worse. Having A::B->foo() and ->foo() or ::foo() and
> A::B->C::foo() is much more inconsistent from my point of view.
> It would be better to change static class separator from :: to ->, but
> it's a BC break


Again, not speaking as an RM, I personally feel we really do have to  
solve this ambiguity problem. I do not agree that this only affects  
"namespace abusers".

That being said we have to stay realistic. What Greg proposes is  
realistic imho. Its essentially reusing an existing OO syntax. The  
same is what we have today with the double colon. While I agree that  
it would not be my natural choice, it seems it solves our real problem  
of the frequently mentioned ambiguity problem. So from that perspetive  
its a step forward from the current syntax.

I know we are getting dangerously close (or are we already back in  
it?) to the namespace separator discussion. I remember back then a lot  
of people were saying lets get the implementation done first and then  
worry about the syntax. I guess we are more or less at this point now.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #40602 — Dmitry Stogov — 2008-09-22T16:07:10+00:00

URL: https://externals.io/message/40569#40602 · In reply to: #40601

Lukas Kahwe Smith wrote:
> 
> 
> 
> > […]
> 
> 
> Again, not speaking as an RM, I personally feel we really do have to
> solve this ambiguity problem. I do not agree that this only affects
> "namespace abusers".
> 
> That being said we have to stay realistic. What Greg proposes is
> realistic imho. Its essentially reusing an existing OO syntax. The same
> is what we have today with the double colon. While I agree that it would
> not be my natural choice, it seems it solves our real problem of the
> frequently mentioned ambiguity problem. So from that perspetive its a
> step forward from the current syntax.

Yes. Changing :: into any other separator solves the functions/static
methods and constants ambiguity, but it also breaks intuitive syntax.

Thanks. Dmitry.

> I know we are getting dangerously close (or are we already back in it?)
> to the namespace separator discussion. I remember back then a lot of
> people were saying lets get the implementation done first and then worry
> about the syntax. I guess we are more or less at this point now.
> 
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

---

## #40603 — Alexey Zakhlestin — 2008-09-22T17:42:53+00:00

URL: https://externals.io/message/40569#40603 · In reply to: #40601

>
> 
>
> > […]
>
>
> Again, not speaking as an RM, I personally feel we really do have to solve
> this ambiguity problem. I do not agree that this only affects "namespace
> abusers".
>
> That being said we have to stay realistic. What Greg proposes is realistic
> imho. Its essentially reusing an existing OO syntax. The same is what we
> have today with the double colon. While I agree that it would not be my
> natural choice, it seems it solves our real problem of the frequently
> mentioned ambiguity problem. So from that perspetive its a step forward from
> the current syntax.

The syntax proposed by Greg seems ok to me. While it is a bit
"unintuitive" at first, it is easily learnable and does it's work

> I know we are getting dangerously close (or are we already back in it?) to
> the namespace separator discussion. I remember back then a lot of people
> were saying lets get the implementation done first and then worry about the
> syntax. I guess we are more or less at this point now.

-- 
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

---

## #40606 — Jochem Maas — 2008-09-22T19:15:52+00:00

URL: https://externals.io/message/40569#40606 · In reply to: #40599

hi Dmirty,

>
> > […]

you didn't answer the question (and AFAIC the readme doesn't either).

> 
> README.namespaces was committed into PHP_5_3 about year ago.

a 14 month old document which doesn't cover the status quo,
and begins with a disingenuous statement about the problem namespaces try to
solve (is that really all there is to namespaces? to avoid typing long class names?
most people have auto-complete features in their editor to take care of that 'problem'
and it really doesn't explain why constants or functions exist in namespaces at all.)

---

## #40607 — Jochem Maas — 2008-09-22T19:26:12+00:00

URL: https://externals.io/message/40569#40607 · In reply to: #40602

Dmitry Stogov schreef:
> 
> Lukas Kahwe Smith wrote:
> > […]

it's unfair to call it inconsistent, the syntax is consistent in it's own
right and uses an operator which is known to mean 'member' in a pre-existing
context.

if it truly can be considered inconsistent then that is only because Greg
proposal avoids BC breakage, inconsistency was inherent because two different
operators were chosen for class scope operator ('->' and '::') which your following
comment demonstrates is technically unnecessary.

> > […]
> 
> Yes. Changing :: into any other separator solves the functions/static
> methods and constants ambiguity, but it also breaks intuitive syntax.

a, it doesn't actually solve all the ambiguity issues, Greg has tried to
point this out. I actually hammered Greg a number of times about the
:: seperator and the fact that changing it fixes the ambiguities ... after
careful consideration he came back to me and pointed out that *most* of
the ambiguities are resolved but not all, simply because (for one) it's still not
possible to distinguish between an aliased namespace and an aliases namespace
name.

b, the presumption that the current syntax is intuitive is completely
subjective. imho it's not intuitive specifically because it's
open to intepretation as to what code refers to (aka ambiguous).

> Thanks. Dmitry.
> 
> > […]

---

## #40608 — Janusz Lewandowski — 2008-09-22T20:02:34+00:00

URL: https://externals.io/message/40569#40608 · In reply to: #40569

Having conflicting names of namespaces and classes is a idea bad from
the ground, and it should not be allowed. PHP should trigger a fatal
error when it sees it. Having two things with the same name is
unnatural and unneeded.

Syntax with -> is unnatural and unreadable. -> is for working with
objects, not for doing such odd things with namespaces. If you will do
this change in PHP, I will never use namespaces in PHP, and I will
start to look for a new language. Probably not only me.

Janusz Lewandowski

---

## #40614 — Larry Garfield — 2008-09-23T03:59:24+00:00

URL: https://externals.io/message/40569#40614 · In reply to: #40601

On Monday 22 September 2008 10:45:33 am Lukas Kahwe Smith wrote:
> 
> > […]
>
> Again, not speaking as an RM, I personally feel we really do have to
> solve this ambiguity problem. I do not agree that this only affects
> "namespace abusers".
>
> That being said we have to stay realistic. What Greg proposes is
> realistic imho. Its essentially reusing an existing OO syntax. The
> same is what we have today with the double colon. While I agree that
> it would not be my natural choice, it seems it solves our real problem
> of the frequently mentioned ambiguity problem. So from that perspetive
> its a step forward from the current syntax.
>
> I know we are getting dangerously close (or are we already back in
> it?) to the namespace separator discussion. I remember back then a lot
> of people were saying lets get the implementation done first and then
> worry about the syntax. I guess we are more or less at this point now.

I think we are already back in it, especially if we're talking about dropping 
functions from namespaces in order to preserve the operator.  I don't find 
reusing a second symbol to be a step up, though.  I can see it making it 
harder to read, not easier, to reuse *both* characters from object resolution 
in a different context.  That just makes my brain hurt even more than 
reusing :: does.

I'd argue there's nothing uniquely intuitive about :: as a namespace operator 
other than the current 5.3 alpha uses it.

-- 
Larry Garfield
larry@garfieldtech.com

---

Next page: https://externals.io/message/40569.md?page=2