# How bad would it be to say/enforce that namespacing can only apply to classes and not normal functions? - Thread: https://externals.io/message/38634 - Original archive: https://news-web.php.net/php.internals/38634 - Started by Richard Quadling on 2008-06-26T09:09:39+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38634 — Richard Quadling — 2008-06-26T09:09:39+00:00 URL: https://externals.io/message/38634#38634 2008/6/26 Derick Rethans : > > > > […] > > Actually, the point that I was trying to make is that we instead of > encouraging this confusion, we should put somewhere in our userland > nameing guidelines that you still would need to provide a prefix to your > (aliased) classnames in order to prevent confusion. But that then > seriously means I see no real good reason still why people want > namespaces with confusing resolving rules (concerning static methods > like Greg points out). > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org > > -- > > > > How bad would it be to say that namespacing can only apply to classes and not normal functions? So. class::static(); namespace::class::static(); namespace::namespace::class::static(); they always work. namespace::function() would fail as namespace would be seen as class. If a class and a namespace share the same name ... namespace::function() vs class:static()... how is anyone, let alone PHP, going to know. It can't. If both forms relate to a valid entity, then it is always a guess as to which is intended. You could make namespace:: have a higher precedence than class:: (or the other way around). But that feels like a fudge rather than a fix. So, maybe, in the short tem, namespacing only applies to classes. It was my understanding that one of the primary reasons for introducing namespacing was to protect against userland_class vs builtin_class collision. Regards, Richard Quadling. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #38635 — Hartmut Holzgraefe — 2008-06-26T09:16:53+00:00 URL: https://externals.io/message/38634#38635 · In reply to: #38634 Richard Quadling wrote: > How bad would it be to say that namespacing can only apply to classes and > not normal functions? i don't see namespacing as an OO only feature, IMHO it is a perfectly valid and useful thing for pure procedural code, too not having namespacing for procedural functions would leave the old ugly concept of bundling functions as static methods within dummy wrapper classes as only option for procedural name space emulation ... which AFAIR was one of the things we wanted to get rid of way back when the whole namespace idea first materialized? -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering --- ## #38636 — Richard Quadling — 2008-06-26T10:41:27+00:00 URL: https://externals.io/message/38634#38636 · In reply to: #38635 2008/6/26 Hartmut Holzgraefe : > Richard Quadling wrote: > > How bad would it be to say that namespacing can only apply to classes and > > […] > > i don't see namespacing as an OO only feature, IMHO it is a perfectly > valid and useful thing for pure procedural code, too > > not having namespacing for procedural functions would leave > the old ugly concept of bundling functions as static methods within > dummy wrapper classes as only option for procedural name space > emulation ... which AFAIR was one of the things we wanted to get > rid of way back when the whole namespace idea first materialized? > > Ok. I see your point and the idea of grouping related functionality into a dummy class full of statics does feel wrong when there is no other benefit, but from a userland code's perspective namespace::function() looks JUST like ugly_bundled_class::static() Internally, sure, they are completely different, but from a users perspective, they are the same thing. Same amount of typing. Same syntax. Nothing to differentiate. So the issue to namespace::function() vs class::static() remains. As I see it either precedence is the answer (user namespaces first, internal namespaces next and global namespace being last) or a different symbol for namespace. Maybe namespace:::function() vs class::static(). Would that be enough? Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #38638 — Brian Moon — 2008-06-26T15:14:57+00:00 URL: https://externals.io/message/38634#38638 · In reply to: #38634 > How bad would it be to say that namespacing can only apply to classes and > not normal functions? Lame, very lame. It would make them unusable for many distributed projects that are not 100% OOP. Wordpress comes to mind. My own Phorum as well. > It was my understanding that one of the primary reasons for introducing > namespacing was to protect against userland_class vs builtin_class > collision. No, that is the OOP propaganda machine at work. Don't listen to the OOP machine. It lies. =) Brian. --- ## #38639 — Stan Vassilev | FM — 2008-06-26T15:57:25+00:00 URL: https://externals.io/message/38634#38639 · In reply to: #38638 > > […] > > Lame, very lame. It would make them unusable for many distributed > projects that are not 100% OOP. Wordpress comes to mind. My own Phorum > as well. > I agree, namespaces need to work for all definition types. I don't see a problem here: 1) ns1::ns2::class::static() and ns1::ns2::namespace::func() is a collision 2) why is it a collision? because we have a class and subnamespace in the same namespace, with the same names. 3) solution therefore is to NOT allow this collision, and end with an error. [Example 1] namespace a::b::c; function foo() {} namespace a::b; class c {} // FATAL ERROR: class collision with existing namespace "a::b::c" [Example 2] namespace a::b; class c {} namespace a::b::c; // FATAL ERROR: namespace collision with existing class "a::b::c" function foo() {} So now, while the syntax may still be ambiguos if a codeline is cut and pasted alone in a blank text file, at least *in context* it can do only one thing: call whatever the user defined/imported/included. If there's a collision, he'll see the error, and take action. --- ## #38641 — Stefan Priebsch — 2008-06-26T17:16:57+00:00 URL: https://externals.io/message/38634#38641 · In reply to: #38639 Hey all, honestly, it is not my intention to raise a new flamewar, but aren't most of these ambiguity problems we talk about due to the fact that :: is used as the namespace separator? Regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F --- ## #38644 — Richard Quadling — 2008-06-26T19:37:45+00:00 URL: https://externals.io/message/38634#38644 · In reply to: #38641 2008/6/26 Stefan Priebsch : > Hey all, > > honestly, it is not my intention to raise a new flamewar, but aren't most > of these ambiguity problems we talk about due to the fact that :: is used as > the namespace separator? > > Regards, > > Stefan > I think so. Considering this _IS_ a new facility I can't see why having 3 :'s wouldn't be a good solution. namespace:::class::static() namespace:::function() No confusion. Clearly defined. No collision. > > -- > > […] > > e-novative GmbH - HR: Amtsgericht München HRB 139407 > Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch > > http://www.e-novative.de - GnuPG Key: 0x7DB67F7F > > > -- > > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #38645 — Steph Fox — 2008-06-26T19:45:44+00:00 URL: https://externals.io/message/38634#38645 · In reply to: #38644 > No confusion. Clearly defined. No collision. ... except possibly between the eyes... We had this discussion ad infinitum in the past. Please, not again? - Steph