This was suggested by Joey Peters about a week ago, and I thought it was a good idea.

The more I think about it, the more I realize how useful namespaces are.

In C++, namespaces are really a way to combine pieces of code without name conflicts, as the D docs say.  They are limited and clunky in C++, as I don't imagine that they were really intended to be a feature.  But D is a pretty language, and a young, impressionable language, and I could see namespaces working out very nicely.

As it is, D has implicit namespaces.  You import a module that has conflicting names, and you can use the fully-qualified identifiers instead. Or you can use them all the time.  This is a nice medium between C++, where conflicting names just conflicted, and C#, where you pretty much must use fully qualified names for _everything_.

However, it would be great to be able to define explicit namespaces; that is, a namespace which MUST be used as part of the identifier's name.  Here are some uses:

1) Singletons.  Singletons are usually represented as an abstract class which has all static methods and variables.  This is a bit cumbersome, as every member must be declared static, and then you have to worry about class behavior such as inheritance.  Really all this technique is is a way to emulate a namespace.  This could all simply be replaced with a namespace declaraction.  This still enforces full name qualification without having to worry about all the class semantics.

2) Grouping functions.  Sometimes in larger classes or modules, you may end up with several functions which operate together, so you end up naming them all with the same prefix.  Namespaces make it possible to apply this "prefix" to a whole group of functions, rather than hardcoding it into each function's name.  And if you want to change the prefix, it only has to be changed in one place, rather than for each function.

3) Other interesting properties.  You could use them as a sort of inner class substitute.  However, unlike defining an actual sub-class, namespaces are still part of the outer class.  The function/member names just have a prefix.  Because of this, these namespaced functions can be overridden/overloaded in derived classes, and participate in polymorphism, unlike classes defined inside other classes.  Another use: say I have a member array whose size I don't want to be messed with, but whose elements I want to be accessible outside the class.  With a namespace, I can make the array private, but I can make a public namespace which contains opIndex and opIndexAssign operators.  Then, when users use the class, they are allowed to access the elements of the array with normal syntax (class.array[5]=10), but they may not use any array properties on the array.  Cool.

I know that this is a minor feature, and that we could probably get by just fine without namespaces.  But why would we implement something as rarely-used as "with" statements or mixins (cool but of very limited usefulness)?  Explicit namespaces seem (to me) as a logical extension to the existing namespacing conventions, and as a sort of "syntactic sugar" feature.

I don't think that a "using" keyword would be a good idea, though, as that was introduced in C++ as a sort of "cheat" to be able to write all the "shorthand" forms of the names.  "using" directives also made it possible to write code that would break if it was moved or if the "using" namespace was moved or changed.  Since the namespacing in D is more intelligent, it shouldn't be necessary to have something like "using."

Hopefully someone else (besides Joey Peters and myself!) will find this interesting/useful.

On Thu, 31 Mar 2005 18:48:52 -0500, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
> This was suggested by Joey Peters about a week ago, and I thought it was a good idea.
>
> The more I think about it, the more I realize how useful namespaces are.

I like you idea/comments, but I have to disagree here:

> But why would we implement something as
> rarely-used as "with" statements or mixins (cool but of very limited
> usefulness)?

IMO Mixins are incredibly useful. Or they will be when Walter "fixes" the limitation that you cannot use them to add non-static members to classes. eg.

class A {
  template opCat(T) { A opCat(T v) {
    ..etc..
  }}
  mixin opCat!(byte);
  mixin opCat!(short);
  mixin opCat!(int);
  mixin opCat!(long);
}

To me they are a great way to reuse generic code.

Regan

Jarrett Billingsley wrote:
> This was suggested by Joey Peters about a week ago, and I thought it was a good idea.
> 
> The more I think about it, the more I realize how useful namespaces are.

I agree.  I've worked on a few projects now with singletons and heavy grouping, and I'm not generally fond of the abstract-class-with-statics approach (though I have used it once or twice).  Singletons can currently also be made by making the constructor protected (or private if your prefer) and creating a single static method to return the singleton instance (which is generated if needed).  This is how Sinbad (a temporarily on-hold OGRE 3d lib port) currently does it, and probably will continue to, only because some of those singleton classes have children.

I guess my question about this is: would D namespaces, like C++ namespaces, be appendable?  Or in other words, if in file "alpha.d" I write something like:

# namespace alpha {
#   protected void[] data;
#   public void doSomething() { ... }
#   public int query(uint flags) { ... }
# }

Could I later, in a file called, say, "alpha_ext.d", write this:

# import alpha;
# namespace alpha {
#   public void[] getRawData() { return alpha.data; }
# }

Or something alike?

-- Chris Sauls

> 1) Singletons.  Singletons are usually represented as an abstract class which has all static methods and variables.  This is a bit cumbersome, as every member must be declared static, and then you have to worry about class behavior such as inheritance.  Really all this technique is is a way to emulate a namespace.  This could all simply be replaced with a namespace declaraction.  This still enforces full name qualification without having to worry about all the class semantics.

This is a fragment of real life singletone in D:
Pay attention on first "static" - it declares the whole body as static.
This is how attributes work in D.

"...every member must be declared static..." - not 'must' but 'may'

(The funny thing that you cannot switch such static off, but you can use
braces form for that)

class Win32Application
{
    static:

    package
    {
        HINSTANCE  hinstance;
        MSG    msg;
        bool      quit;
        string[]  argv;
        string     path;
        void function() onStartCallback;
        void function() onStopCallback;
    }

   void ignition()
   {
         RegisterWindowClasses();
         if( onStartCallback ) onStartCallback();
   }
}

IMHO, current, "a la Java", namespacing schema
is just as good as simple and don't need to be
modified.

Andrew Fedoniouk.
http://terrainformatica.com

> I guess my question about this is: would D namespaces, like C++ namespaces, be appendable?  Or in other words, if in file "alpha.d" I write something like:
>
> # namespace alpha {
> #   protected void[] data;
> #   public void doSomething() { ... }
> #   public int query(uint flags) { ... }
> # }
>
> Could I later, in a file called, say, "alpha_ext.d", write this:
>
> # import alpha;
> # namespace alpha {
> #   public void[] getRawData() { return alpha.data; }
> # }
>
> Or something alike?
>
> -- Chris Sauls

If namespaces were to act like static classes, then appending stuff to it would be like using the partial classes C# has. I'm  not sure how relevant it is to add partial classes. http://blogs.msdn.com/danielfe/archive/2004/02/02/66463.aspx Maybe it would be a fun new D feature request?

"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:d2i4il$28d1$1@digitaldaemon.com...
> Jarrett Billingsley wrote:
> I guess my question about this is: would D namespaces, like C++
> namespaces, be appendable?

That's an interesting idea.  I don't see why it wouldn't be possible.

But then how would the namespace be resolved if it spanned modules?  Would the module namespace still be in effect, making the explicit namespace a sub-namespace of the module?

Or would explicit namespaces sort of override their module namespace?  That seems like it'd be a bit inconsistent, though.

Perhaps namespace support would have to be accompanied with some more clarifications on modules.