How bad would it be to say/enforce that namespacing can only apply to classes and not normal functions?

2008/6/26 Hartmut Holzgraefe hartmut@mysql.com:

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?

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!"

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.

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.