Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20899
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <BE.5B.14828.D2DCD834@pb1.pair.com>
To: internals@lists.php.net
References: <000601c5f583$2490afb0$5d54edc6@jake>
Date: Wed, 30 Nov 2005 11:02:07 -0500
Lines: 110
Subject: Re: Desired namespace behavoir
From: jrhernandez05@gmail.com ("Jessie Hernandez")

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