Everything

php

Desired namespace behavoir

php.internals

Bob Silva

20 years ago

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

Jessie Hernandez

20 years ago

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

Oliver Grätz

20 years ago

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...)

Jessie Hernandez

20 years ago

Hi Oliver,

"Oliver Grätz" <oliver.graetz@arcor.de> wrote in message
news:F3.86.14828.8833E834@pb1.pair.com...

> 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?
>

This has been in the patch practically since day 1!

import class ns:class1 as ns_class1;
import function ns:func1 as ns_func1;

> 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?
>

Please explain what you mean.

Regards,

Jessie

Oliver Grätz

20 years ago

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

Jessie Hernandez

20 years ago

Oliver Grätz wrote:

> 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.
>

This is definitely doable, and shouldn't be too difficult. Anyone else
have any opinions on this?

Regards,

Jessie

Bart de Boer

20 years ago

>> 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();

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.

Bob Silva

20 years ago

If Mike doesn't want to use namespaces, then Mike shouldn't use Jessies
package.

Bob

Oliver Grätz

20 years ago

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

l0t3k

20 years ago

>> 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?

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

l0t3k

Oliver Grätz

20 years ago

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