# Desired namespace behavoir

- Thread: https://externals.io/message/20874
- Original archive: https://news-web.php.net/php.internals/20874
- Started by Bob Silva on 2005-11-30T07:53:25+00:00
- Messages: 8
- 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

---

## #20874 — Bob Silva — 2005-11-30T07:53:25+00:00

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

Looking for some feedback on what the expected behavior should be for class
and/or constant ambiguity within namespaces. For instance:

 

Classes.php:

 

namespace A {

    const FOO = 123;

    class Bar { . }

    class FooBaz { . }

}

 

namespace B {

    const FOO = 456;

    class Bar { . }

    class FooBar { . }

}

 

class Bar { . }

define('FOO', 789);

 

File.php:

 

import namespace A;

import namespace B;

 

 

$c = new Bar(FOO); // ambiguous classname/constant

 

Compile-time error on namespace B import? Or runtime error on ambiguous
class creation?

 

Jessie, how does your patch handle it? 

 

Looking at the modules patch, it appears to be a compile time error when the
second class is defined since it is based on zend_class_entry and
CG(class_tables).

 

 

Also, neither patch has scoped imports, they are global. Is this the
"preferred" method? Maybe it's the only method, not sure yet, still
scratching the surface here.

 

Bob

---

## #20899 — Jessie Hernandez — 2005-11-30T16:02:07+00:00

URL: https://externals.io/message/20874#20899 · In reply to: #20874

Hello Bob,

""Bob Silva"" <me@bobsilva.com> wrote in message
news:000601c5f583$2490afb0$5d54edc6@jake...
> Looking for some feedback on what the expected behavior should be for
class
> and/or constant ambiguity within namespaces. For instance:
>
>
>
> Classes.php:
>
>
>
> namespace A {
>
>     const FOO = 123;
>
>     class Bar { . }
>
>     class FooBaz { . }
>
> }
>
>
>
> namespace B {
>
>     const FOO = 456;
>
>     class Bar { . }
>
>     class FooBar { . }
>
> }
>
>
>
> class Bar { . }
>
> define('FOO', 789);
>
>
>
> File.php:
>
>
>
> import namespace A;
>
> import namespace B;
>
>
>
>
>
> $c = new Bar(FOO); // ambiguous classname/constant
>
>
>
> Compile-time error on namespace B import? Or runtime error on ambiguous
> class creation?
>
>
>
> Jessie, how does your patch handle it?
>

In this case the FOO define will be used. When you do a namespace import,
you can really only use classes without the namespace prefix (since
__autoload exists). To reference a function name without the prefix, you
must import it directly, as:

import function A:::my_func;

To have the same behavior for functions in namespace imports, a global
__call function would need to be defined (this would serve as the
"__autoload" for functions.

Currently in my patch, I have no such thing as "importing a constant"
directly. You must always reference the constant with the namespace prefix
(that's why the above example would work). I don't know if this should be
added or not (that's one of the things I'm going to add to my list of items
to be discussed).

>
> Looking at the modules patch, it appears to be a compile time error when
the
> second class is defined since it is based on zend_class_entry and
> CG(class_tables).
>
>
>
>
>
> Also, neither patch has scoped imports, they are global. Is this the
> "preferred" method? Maybe it's the only method, not sure yet, still
> scratching the surface here.
>

I didn't necessarily implement it this way because it was "preferred", but
because it was easy-to-implement. Having said that, I don't see a need for
scoped imports.


Regards,

Jessie

---

## #20916 — oliver.graetz@arcor.de — 2005-11-30T23:19:31+00:00

URL: https://externals.io/message/20874#20916 · In reply to: #20899

Jessie Hernandez schrieb:
> In this case the FOO define will be used. When you do a namespace import,
> you can really only use classes without the namespace prefix (since
> __autoload exists). To reference a function name without the prefix, you
> must import it directly, as:
> 
> import function A:::my_func;
> 
> To have the same behavior for functions in namespace imports, a global
> __call function would need to be defined (this would serve as the
> "__autoload" for functions.

Hi Jessie!

First of all, what about the "import ... as ..." syntax?

And then, I wrote about a "auto prefix simulation" mode.
This could give the prefix evangelists what they want without stopping
others from using namespaces. How would that fit in here? Or is this
suffering the same problems as here with only having
autoscope-functionality for classes?

OLLi

PS: Sheesh, today the connection timeouts to news.php.net were getting
on my nerves again. Is this just an issue with Thunderbird? I guess,
other users seem to have these too (looking at the huge amount of double
posts, that tend to happen alongside connection timeout stuff...)

---

## #20927 — oliver.graetz@arcor.de — 2005-12-01T01:09:42+00:00

URL: https://externals.io/message/20874#20927

Jessie Hernandez schrieb:

> Please explain what you mean.

Didn't you get my mail? OK, I'll put it in here:

---------------------------------------------------------
I already brought this up once: How difficult is it to introduce an
option to php.ini which has its standard setting in such a way that
every encountered namespace is automagically translated into "classic
prefixing" style?

Let's say: Mike doesn't want to use namespaces but he wants to use a
package from Jessie. Jessie uses namespaces. Mike has his PHP configured
to "auto-prefix-import" everything. So if he uses your file foo.php containg

  namespace JessieStuff{ class Foo { ... } }

in conjunction with this setting would enable him to

  require_once('foo.php');
  $x=new JessieStuff_Foo();

This enables people who don't like namespaces to disregard them. No
import, no ::: and all the fresh fun when name collisions occur. Of
course, their code wouldn't be easily usable by those using namespaces,
but that's their problem not ours.
---------------------------------------------------------

This simply means automating the "as" option for EVERYTHING inside
namespaces for people that hate them.

OLLi

---

## #20932 — Bart de Boer — 2005-12-01T07:45:19+00:00

URL: https://externals.io/message/20874#20932

> > […]

So, if namespace JessieStuff contains multiple classes. They would all 
become JessieStuff_ClassName.

Assuming the package relies on its own classes, it wouldn't be able to 
call them anymore because all their names have changed.

---

## #20953 — l0t3k — 2005-12-01T15:22:55+00:00

URL: https://externals.io/message/20874#20953

> > […]

Language behaviour should absolutely NOT depend on an .ini setting.

l0t3k

---

## #20958 — oliver.graetz@arcor.de — 2005-12-01T16:03:11+00:00

URL: https://externals.io/message/20874#20958 · In reply to: #20932

Bart de Boer schrieb:
> So, if namespace JessieStuff contains multiple classes. They would all 
> become JessieStuff_ClassName.
> 
> Assuming the package relies on its own classes, it wouldn't be able to 
> call them anymore because all their names have changed.

First of all, everything INSIDE a namespace is supposed to be able to
use its siblings without any namespace operators or prefixes. This is
out of scope here. The "import with as" is supposed to be aliasing, not
replacing.

And for the auto-prefixing, I think of it as an aggressive use of the
"as" option of the import statement. An import makes everything that is
inside a namespace available in the global namespace. Normally, the
names from inside the namespace are kept, so one could use SimpleClass
instead of JessieStuff:::SimpleClass. To avoid collisions with
OllStuff::SimpleClass, there is the "as" option. And my suggestion is to
give Mike an automatism for import with "as" that emulates the current
recommendation of prefixing everything:

  /*
   * this encounters a namespace. The auto-prefix-import option
   * is active so EVERYTHING is inside the namespace is imported
   * with a prefix of "JessieStuff_".
   */
  require 'JessiePackage.php';
  $x=new JessieStuff_SimpleClass();

This implements a one-way-availability for packages using namespaces to
users hating them. Of course, Mike shouldn't count on successfully
sharing his code using Jessie's stuff with others that prefer to use the
namespaces.

OLLi

References: http://en.wikipedia.org/wiki/XML_namespace

---

## #20959 — oliver.graetz@arcor.de — 2005-12-01T16:10:04+00:00

URL: https://externals.io/message/20874#20959 · In reply to: #20953

l0t3k schrieb:

> Language behaviour should absolutely NOT depend on an .ini setting.

Using an .ini setting was just an idea so there would be a possibility
to have namespaces totally "hidden" from the beginning programmer. This
honors the KISS priciple: You require() some package and don't even need
to know what namespaces are despite the fact that the package actually
uses them!

Of couse it would also be possible to simply activate this by some
function like

  core_namespaces_autoprefix(true);

OLLi