www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Namespacing!

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
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 

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.
Mar 31 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
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
Mar 31 2005
prev sibling next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
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:







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






Or something alike?

-- Chris Sauls
Mar 31 2005
next sibling parent "Joey Peters" <squirrel nidhogg.com> writes:
 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:







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






 Or something alike?

 -- Chris Sauls


If namespaces were to act like static classes, then appending stuff to it 

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?
Apr 01 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Mar 31 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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
Mar 31 2005