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