Jessie Hernandez wrote:
I thought global names were considered in the patch, but now that I
re-read Dmitry's post, only symbols in the namespace and internal
symbols are considered.
I read through most of the posts regarding namespaces, but could not
find a reason why global names are not l
Sam Barrow wrote:
> I agree with this 100%, is this something that could be changed? I don't
> see a reason behind it.
>
> On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
>
>> internal class/function with the same name.
>>
>> Dmitry, what's the reason this lookup logic wasn't used in
I agree with this 100%, is this something that could be changed? I don't
see a reason behind it.
On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
>
> internal class/function with the same name.
>
> Dmitry, what's the reason this lookup logic wasn't used in your patch?
>
--
PHP Inter
I thought global names were considered in the patch, but now that I
re-read Dmitry's post, only symbols in the namespace and internal
symbols are considered.
I read through most of the posts regarding namespaces, but could not
find a reason why global names are not looked up. Classes/functions
Jessie Hernandez wrote:
> Hi Greg,
>
> How about this: any non-namespaced file that uses "use" statements is
> implicitly put into the __php__ namespace (or whatever other name is
> chosen, or having the namespace name be the path of the file)? With
> this, "use" will never import any symbols into
Hi Greg,
How about this: any non-namespaced file that uses "use" statements is
implicitly put into the __php__ namespace (or whatever other name is
chosen, or having the namespace name be the path of the file)? With
this, "use" will never import any symbols into the global namespace.
Regard
Matthias Pigulla wrote:
>> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
>
>> Exactly - which is why you should never put classes, functions or
>> constants in the __php__ namespace. The convention I am proposing
>> is to only use __php__ for code that *uses* re-usable components,
>> not *declar
In C++, STD was just a normal namespace with some classes and functions
in it, you didn't have to say "use std" unless you wanted to use
functions in the std namespace.
The "php::" namespace could just be a container for all of the functions
and classes that are currently thrown into the global na
On Friday 07 December 2007, Gregory Beaver wrote:
> > If new, future core extensions showed up in a reserved PHP::
> > namespace, you would be >:-).
>
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is to
> on
> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is
> to
> only use __php__ for code that *uses* re-usable components, not
> *declares* them.
Let alone __php__.
On 07 December 2007 17:36, Gregory Beaver wrote:
> The suggestion to make "namespace __php__;" implicit is very
> interesting, but would defeat its purpose, which is to separate
> declarations from use.
Oh, I missed that little wrinkle -- I did say I was only skimming! I guess it
could still be
Matthias Pigulla wrote:
>> 1) recommend all global non-namespaced code that wishes to import
>> namespaced code via "use Namespace::Classname" add a "namespace
>> __php__;" at the top of the file, and that the __php__ namespace be
>> reserved for use by end-user applications.
>
>
>> 5) namespa
> 1) recommend all global non-namespaced code that wishes to import
> namespaced code via "use Namespace::Classname" add a "namespace
> __php__;" at the top of the file, and that the __php__ namespace be
> reserved for use by end-user applications.
> 5) namespaces provide these benefits that are
13 matches
Mail list logo
