Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Hello,
On Sat, Sep 20, 2008 at 5:59 AM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> There is a problem in the namespace implementation. This code demonstrates
> the issue:
>
> code.inc:
> namespace foo;
> class test {
> const my = 1;
> static function bar(){}
> }
>
> namespace foo::test;
> const my = 2;
> function bar(){}
> ?>
>
> main.php:
> include 'code.inc';
> foo::test::bar(); // always calls namespace function
> call_user_func(array('foo::test', 'bar')); // the only way to call static
> method
> echo foo::test::my; // always 2
> $a = new foo::test;
> echo $a::my; // the only way to access foo::test::my
> ?>
>
> There are 5 ways to solve this:
>
> 1) document it and hope no one uses it [this is the current strategy, minus
> the documentation part]
> 2) add a fatal error on conflicting names.
>
> http://pear.php.net/~greg/ns_method.func.conflict.patch.txt
>
> Unfortunately, this can only work for methods/functions, as namespace
> constants are actually defined at run-time, and so conflicts can't be
> detected until then, which does not provide any benefit (you want to catch
> this conflict at compile-time).
>
> 3) create a disambiguation method.
>
> http://pear.php.net/~greg/ns.func_const.patch.txt
>
> This introduces function:: and const:: as prefixes to disambiguate.
>
> function::foo::test::bar(); // always calls namespace function
> foo::test::bar(); // always calls static method if defined, falls back to ns
> function if not
> const::foo::test::my; // namespace constant
> foo::test::my; // class constant
> ?>
>
> The drawback of this approach is that "foo::test::bar" will always look for
> class "foo::test", which means if autoload is defined, it will be called for
> all non-prefixed function calls. Unfortunately, the only other keyword for
> disambiguating would be "class::" as in "class::foo::test::bar()" but this
> is excessively confusing.
>
> 4) remove functions/constants from namespaces
> 5) a simply syntax change to namespaces, introducing a new concept:
> namespace element.
>
> A namespace element is a class, function or constant defined within a
> namespace declaration:
>
> namespace foo;
> class bar {} // class element bar in namespace foo
> function bar(){} // function element bar in namespace foo
> const bar=1; // const element bar in namespace foo
> ?>
>
> This is similar to class elements:
>
> class foo {
> function bar(){} // method element bar in class foo
> const bar=1; // constant element bar in class foo
> public $bar=1; // variable element bar in class foo
> }
> ?>
>
> Currently, this code:
>
> namespace foo::bar;
> class buh{}
> ?>
>
> creates a class named "foo::bar::buh", essentially joining the namespace
> "foo::bar" and its class element "buh" with the separator "::". This turns
> out to be the root of the problem with the conflicts between class elements
> and namespace elements. The last patch introduces a new namespace element
> operator to delineate the boundary between namespace name and element name.
> For the patch, I recycled T_OBJECT_OPERATOR (->).
>
> current way:
> foo::bar->test(); // namespace foo::bar, call to function element test()
> foo->bar::test(); // namespace foo, call to static method element test() in
> class element bar
> foo->myconst; // namespace foo constant myconst
> foo::myconst; // class foo constant myconst
> ?>
>
> The patch is at:
>
> http://pear.php.net/~greg/ns.element.patch.txt
>
> This is the most extensive change. The patch preserves :: as global element
> accessor (::strlen() calls strlen internal function, for instance). I'm
> happy to answer any other questions.
>
> So, these are the choices. I suggest we all take a rational look at the
> options, and understand the consequences of each, and make the best choice
> possible.
>
> Thanks,
> Greg
Good work, but I (and I'm probably not alone) can't really keep up
with all those namespace threads and proposals for changes and
resolution fixes and this and that,so :
Please use our nice RFC system!
Regards
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
2008/9/20 Etienne Kneuss <[EMAIL PROTECTED]>:
> Hello,
>
> On Sat, Sep 20, 2008 at 5:59 AM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> There is a problem in the namespace implementation. This code demonstrates
>> the issue:
>>
>> code.inc:
>> > namespace foo;
>> class test {
>> const my = 1;
>> static function bar(){}
>> }
>>
>> namespace foo::test;
>> const my = 2;
>> function bar(){}
>> ?>
>>
>> main.php:
>> > include 'code.inc';
>> foo::test::bar(); // always calls namespace function
>> call_user_func(array('foo::test', 'bar')); // the only way to call static
>> method
>> echo foo::test::my; // always 2
>> $a = new foo::test;
>> echo $a::my; // the only way to access foo::test::my
>> ?>
>>
>> There are 5 ways to solve this:
>>
>> 1) document it and hope no one uses it [this is the current strategy, minus
>> the documentation part]
>> 2) add a fatal error on conflicting names.
>>
>> http://pear.php.net/~greg/ns_method.func.conflict.patch.txt
>>
>> Unfortunately, this can only work for methods/functions, as namespace
>> constants are actually defined at run-time, and so conflicts can't be
>> detected until then, which does not provide any benefit (you want to catch
>> this conflict at compile-time).
>>
>> 3) create a disambiguation method.
>>
>> http://pear.php.net/~greg/ns.func_const.patch.txt
>>
>> This introduces function:: and const:: as prefixes to disambiguate.
>>
>> > function::foo::test::bar(); // always calls namespace function
>> foo::test::bar(); // always calls static method if defined, falls back to ns
>> function if not
>> const::foo::test::my; // namespace constant
>> foo::test::my; // class constant
>> ?>
>>
>> The drawback of this approach is that "foo::test::bar" will always look for
>> class "foo::test", which means if autoload is defined, it will be called for
>> all non-prefixed function calls. Unfortunately, the only other keyword for
>> disambiguating would be "class::" as in "class::foo::test::bar()" but this
>> is excessively confusing.
>>
>> 4) remove functions/constants from namespaces
>> 5) a simply syntax change to namespaces, introducing a new concept:
>> namespace element.
>>
>> A namespace element is a class, function or constant defined within a
>> namespace declaration:
>>
>> > namespace foo;
>> class bar {} // class element bar in namespace foo
>> function bar(){} // function element bar in namespace foo
>> const bar=1; // const element bar in namespace foo
>> ?>
>>
>> This is similar to class elements:
>>
>> > class foo {
>> function bar(){} // method element bar in class foo
>> const bar=1; // constant element bar in class foo
>> public $bar=1; // variable element bar in class foo
>> }
>> ?>
>>
>> Currently, this code:
>>
>> > namespace foo::bar;
>> class buh{}
>> ?>
>>
>> creates a class named "foo::bar::buh", essentially joining the namespace
>> "foo::bar" and its class element "buh" with the separator "::". This turns
>> out to be the root of the problem with the conflicts between class elements
>> and namespace elements. The last patch introduces a new namespace element
>> operator to delineate the boundary between namespace name and element name.
>> For the patch, I recycled T_OBJECT_OPERATOR (->).
>>
>> current way:
>> > foo::bar->test(); // namespace foo::bar, call to function element test()
>> foo->bar::test(); // namespace foo, call to static method element test() in
>> class element bar
>> foo->myconst; // namespace foo constant myconst
>> foo::myconst; // class foo constant myconst
>> ?>
>>
>> The patch is at:
>>
>> http://pear.php.net/~greg/ns.element.patch.txt
>>
>> This is the most extensive change. The patch preserves :: as global element
>> accessor (::strlen() calls strlen internal function, for instance). I'm
>> happy to answer any other questions.
>>
>> So, these are the choices. I suggest we all take a rational look at the
>> options, and understand the consequences of each, and make the best choice
>> possible.
>>
>> Thanks,
>> Greg
>
> Good work, but I (and I'm probably not alone) can't really keep up
> with all those namespace threads and proposals for changes and
> resolution fixes and this and that,so :
>
> Please use our nice RFC system!
>
> Regards
>
> --
> Etienne Kneuss
> http://www.colder.ch
>
> Men never do evil so completely and cheerfully as
> when they do it from a religious conviction.
> -- Pascal
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
How feasible would it be to use # as the namespace separator. I know #
is used for comments, but with /* */ and // that all seems covered.
namespace#function() vs class::static()
Seems like a winner. Just a whole ton of BC though for those using #
for comments.
Regards,
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Seems like a winner. Just a whole ton of BC though for those using # for comments. Yep, so forget it. Or were you doing a Jani? ;) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
I can't see how this can break existing code... '#' is usually used at the beginning of a line or after ';' will->not->be->evaluated() ?> Regards, On Sat, Sep 20, 2008 at 8:57 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > Seems like a winner. Just a whole ton of BC though for those using # >> for comments. >> > > Yep, so forget it. Or were you doing a Jani? ;) > > - Steph > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Diego Feitosa www.dnfeitosa.com Caelum - Ensino e Soluções em Java [EMAIL PROTECTED] www.caelum.com.br
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Steph Fox schreef: Seems like a winner. Just a whole ton of BC though for those using # for comments. Yep, so forget it. Or were you doing a Jani? ;) It seems to hav escaped everyone that Greg's latest proposal doesn't change the namespace seperator token, instead it comes with a new concept of namespace member [token]. ambiguity related to the 'use' statements remains regardless of what the namespace seperator is ... therefore the proposal for a new operator that allows to explicitly reference namespace members: and obviously BC dictates that '#' cannot be considered, but that's moot anyhow. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Hi Jochem, It seems to hav escaped everyone that Greg's latest proposal doesn't change the namespace seperator token, instead it comes with a new concept of namespace member [token]. No, that didn't escape me at all. I was responding to the OP. To be clear, I have worked with Greg. The experience left me with large amounts of respect for his creativity and analytical abilities. They exceed mine by a number of quadzillions. That doesn't mean Greg's always in the right, but it does mean he's always worth hearing. I know for sure I'm not the only person on this list who sees him that way, and most of the others have far more influence than I do. Next time, perhaps you and I should both let sleeping dogs lie ;) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
On Saturday 20 September 2008 6:43:41 pm Richard Quadling wrote:
> >> 5) a simply syntax change to namespaces, introducing a new concept:
> >> namespace element.
> >>
> >> A namespace element is a class, function or constant defined within a
> >> namespace declaration:
> >>
> >> >> namespace foo;
> >> class bar {} // class element bar in namespace foo
> >> function bar(){} // function element bar in namespace foo
> >> const bar=1; // const element bar in namespace foo
> >> ?>
> >>
> >> This is similar to class elements:
> >>
> >> >> class foo {
> >> function bar(){} // method element bar in class foo
> >> const bar=1; // constant element bar in class foo
> >> public $bar=1; // variable element bar in class foo
> >> }
> >> ?>
> >>
> >> Currently, this code:
> >>
> >> >> namespace foo::bar;
> >> class buh{}
> >> ?>
> >>
> >> creates a class named "foo::bar::buh", essentially joining the namespace
> >> "foo::bar" and its class element "buh" with the separator "::". This
> >> turns out to be the root of the problem with the conflicts between class
> >> elements and namespace elements. The last patch introduces a new
> >> namespace element operator to delineate the boundary between namespace
> >> name and element name. For the patch, I recycled T_OBJECT_OPERATOR (->).
> >>
> >> current way:
> >> >> foo::bar->test(); // namespace foo::bar, call to function element test()
> >> foo->bar::test(); // namespace foo, call to static method element test()
> >> in class element bar
> >> foo->myconst; // namespace foo constant myconst
> >> foo::myconst; // class foo constant myconst
> >> ?>
> >>
> >> The patch is at:
> >>
> >> http://pear.php.net/~greg/ns.element.patch.txt
> >>
> >> This is the most extensive change. The patch preserves :: as global
> >> element accessor (::strlen() calls strlen internal function, for
> >> instance). I'm happy to answer any other questions.
> >>
> >> So, these are the choices. I suggest we all take a rational look at the
> >> options, and understand the consequences of each, and make the best
> >> choice possible.
> >>
> >> Thanks,
> >> Greg
> >
> > Good work, but I (and I'm probably not alone) can't really keep up
> > with all those namespace threads and proposals for changes and
> > resolution fixes and this and that,so :
> >
> > Please use our nice RFC system!
> >
> > Regards
> >
> > --
> > Etienne Kneuss
> > http://www.colder.ch
> >
> > Men never do evil so completely and cheerfully as
> > when they do it from a religious conviction.
> > -- Pascal
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> How feasible would it be to use # as the namespace separator. I know #
> is used for comments, but with /* */ and // that all seems covered.
>
> namespace#function() vs class::static()
>
> Seems like a winner. Just a whole ton of BC though for those using #
> for comments.
I agree that #5 seems like the best solution. The problem is caused by the
double meaning of ::. All of the other solutions feel like bandaids.
Of course, the problem then is finding a symbol that is not already used. I
don't think reusing -> is any wiser than reusing ::. # would be great if it
wasn't already in use, but that sort of change is really not appropriate for
5.3. What other symbols are available or could be created? (::: has been
suggested and would give the opportunity to introduce more Hebrew into the
language parser...)
--
Larry Garfield
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Larry Garfield wrote:
> On Saturday 20 September 2008 6:43:41 pm Richard Quadling wrote:
>
5) a simply syntax change to namespaces, introducing a new concept:
namespace element.
A namespace element is a class, function or constant defined within a
namespace declaration:
>>> namespace foo;
class bar {} // class element bar in namespace foo
function bar(){} // function element bar in namespace foo
const bar=1; // const element bar in namespace foo
?>
This is similar to class elements:
>>> class foo {
function bar(){} // method element bar in class foo
const bar=1; // constant element bar in class foo
public $bar=1; // variable element bar in class foo
}
?>
Currently, this code:
>>> namespace foo::bar;
class buh{}
?>
creates a class named "foo::bar::buh", essentially joining the namespace
"foo::bar" and its class element "buh" with the separator "::". This
turns out to be the root of the problem with the conflicts between class
elements and namespace elements. The last patch introduces a new
namespace element operator to delineate the boundary between namespace
name and element name. For the patch, I recycled T_OBJECT_OPERATOR (->).
current way:
>>> foo::bar->test(); // namespace foo::bar, call to function element test()
foo->bar::test(); // namespace foo, call to static method element test()
in class element bar
foo->myconst; // namespace foo constant myconst
foo::myconst; // class foo constant myconst
?>
The patch is at:
http://pear.php.net/~greg/ns.element.patch.txt
This is the most extensive change. The patch preserves :: as global
element accessor (::strlen() calls strlen internal function, for
instance). I'm happy to answer any other questions.
[snip]
> I agree that #5 seems like the best solution. The problem is caused by the
> double meaning of ::. All of the other solutions feel like bandaids.
>
> Of course, the problem then is finding a symbol that is not already used. I
> don't think reusing -> is any wiser than reusing ::. # would be great if it
Let's be clear. Here is a sample of code with the new syntax:
is only used once
// to specify the boundary between namespace name and namespace member.
$a = new name::still::has::double::colon->blow;
$a = new colon->blow;
// static method call
colon->blow::hard();
// or
name::still::has::double::colon->blow::hard();
// ns constant
echo colon->oscopy;
namespace blow;
function hard(){}
namespace a::third::name;
// demonstrate importing a class name
// which is different from importing a namespace name
use name::still::has::double::colon->blow;
// class static method
blow::hard();
// namespace function
::blow->hard();
// class constant
echo blow::byblow;
?>
Two important things to note:
- ambiguity between namespace name and class name is eliminated
- this separator is self-documenting. One does not need to grep source
code to determine whether blah->thing is a namespaced function or a
static method of class blah. The same is true of use statements. It is
crystal clear whether we are importing a namespace or a class name.
This will make debugging someone else's code a lot easier than it
otherwise would be.
Jochem has informed me he is taking care of the wiki RFC for this stuff.
I am allergic to wikis, unfortunately.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Larry Garfield a écrit : I agree that #5 seems like the best solution. The problem is caused by the double meaning of ::. All of the other solutions feel like bandaids. They are not a double meaning : it is a scope resolver. Like in C++. So please all stop this war about namespaces, and look where it was resolved in other languages. It will be wisely :) -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Steph Fox schreef: Hi Jochem, It seems to hav escaped everyone that Greg's latest proposal doesn't change the namespace seperator token, instead it comes with a new concept of namespace member [token]. No, that didn't escape me at all. oh, good! I was responding to the OP. To be clear, I have worked with Greg. The experience left me with large amounts of respect for his creativity and analytical abilities. They exceed mine by a number of quadzillions. I've been conversing with him over the last couple of weeks regarding namespaces off-list and have every reason to second that thought. That doesn't mean Greg's always in the right, but it does mean he's always worth hearing. I know for sure I'm not the only person on this list who sees him that way, and most of the others have far more influence than I do. which makes it all the more sad that the only person taking a real interest in his [latest namespace] proposal is the one person who's completely adamant that there is nothing in the current namespace implementation that needs addressing (all issues come down to 'your using it wrong') Next time, perhaps you and I should both let sleeping dogs lie ;) I don't get the use of that idiom in this context. I think the 'namespace' dog has been up and about for a while already, granted some would like to see it put down permanently :-) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Having conflicting names of namespaces and classes is a idea bad from the ground, and it should not be allowed. PHP should trigger a fatal error when it sees it. Having two things with the same name is unnatural and unneeded. Syntax with -> is unnatural and unreadable. -> is for working with objects, not for doing such odd things with namespaces. If you will do this change in PHP, I will never use namespaces in PHP, and I will start to look for a new language. Probably not only me. Janusz Lewandowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
On Fri, 19 Sep 2008, Greg Beaver wrote:
> Hi all,
>
> There is a problem in the namespace implementation. This code demonstrates
> the issue:
>
> code.inc:
> namespace foo;
> class test {
> const my = 1;
> static function bar(){}
> }
>
> namespace foo::test;
> const my = 2;
> function bar(){}
> ?>
>
> main.php:
> include 'code.inc';
> foo::test::bar(); // always calls namespace function
> call_user_func(array('foo::test', 'bar')); // the only way to call static
> method
> echo foo::test::my; // always 2
> $a = new foo::test;
> echo $a::my; // the only way to access foo::test::my
> ?>
>
> There are 5 ways to solve this:
>
> 1) document it and hope no one uses it [this is the current strategy, minus
> the documentation part]
> 2) add a fatal error on conflicting names.
Uh, if we don't have functions in namespaces, then the second "function
bar(){}" would define the bar function in the global scope only and not
as part of the foo::test namespace... so one more reason to remove
functions (and constants) from namespaces?
regards,
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Derick Rethans schreef:
> On Fri, 19 Sep 2008, Greg Beaver wrote:
>
>> Hi all,
>>
>> There is a problem in the namespace implementation. This code demonstrates
>> the issue:
>>
>> code.inc:
>> > namespace foo;
>> class test {
>> const my = 1;
>> static function bar(){}
>> }
>>
>> namespace foo::test;
>> const my = 2;
>> function bar(){}
>> ?>
>>
>> main.php:
>> > include 'code.inc';
>> foo::test::bar(); // always calls namespace function
>> call_user_func(array('foo::test', 'bar')); // the only way to call static
>> method
>> echo foo::test::my; // always 2
>> $a = new foo::test;
>> echo $a::my; // the only way to access foo::test::my
>> ?>
>>
>> There are 5 ways to solve this:
>>
>> 1) document it and hope no one uses it [this is the current strategy, minus
>> the documentation part]
>> 2) add a fatal error on conflicting names.
>
> Uh, if we don't have functions in namespaces, then the second "function
> bar(){}" would define the bar function in the global scope only and not
> as part of the foo::test namespace... so one more reason to remove
> functions (and constants) from namespaces?
I don't follow the logic. if we don't have functions in namespaces the second
"function bar(){}" would be a parse error, no?
>
> regards,
> Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
