www.digitalmars.com         C & C++   DMDScript  

D - Modules (namespaces)

reply "Matthew Wilson" <dmd synesis.com.au> writes:
I wanted to follow up on the earlier post by Helmut, and suggest we adopt an
agreed module (namespace for the C++ folks; package for the Java ones)
naming convention.

Helmut points out quite rightly that names such as "string", "windows", etc.
are not adequate.

We can go the whole Java hog, and prefix everything with reversed
namespaces, as in

    com.digitalmars.phobos.windows;
    org.synsoft.win32.perf;

Alternatively, we can be a bit more relaxed and, at least for phobos, have
the following

    phobos.windows.

The other organisations could do without the org, I suppose, but I guess the
full thing is the safest.

So, the options are - and let's take a vote - as follows:

 1. Status quo / laissez faire, and live with the conflicts
 2. Strict naming (including com/org) for all components, e.g.
org.synsoft.win32.perf
 3. Strict naming (including com/org) for all components, except DMD stuff,
which goes in phobos.xyz
 4. Semi-strict naming (excluding com/org) for all components, e.g.
synsoft.win32.perf
 3. Semi-strict naming (including com/org) for all components, except DMD
stuff, which goes in phobos.xyz

I think that's all reasonable permutations. Please vote for the one you
prefer. (Of course, if I've missed one, please add them numbered from 6
onwards)

I'll start: I vote 3.
Apr 15 2003
next sibling parent "Nic Tiger" <tiger7 progtech.ru> writes:
Vote for: 3
I think it is most reasonable.

Nic Tiger.
Apr 15 2003
prev sibling next sibling parent reply C <cc.news gateway.mirlex.com> writes:
Matthew Wilson wrote:

 I wanted to follow up on the earlier post by Helmut, and suggest we adopt an
 agreed module (namespace for the C++ folks; package for the Java ones)
 naming convention.
 
 Helmut points out quite rightly that names such as "string", "windows", etc.
 are not adequate.
 
 We can go the whole Java hog, and prefix everything with reversed
 namespaces, as in
 
     com.digitalmars.phobos.windows;
     org.synsoft.win32.perf;
 
 Alternatively, we can be a bit more relaxed and, at least for phobos, have
 the following
 
     phobos.windows.
 
 The other organisations could do without the org, I suppose, but I guess the
 full thing is the safest.
 
 So, the options are - and let's take a vote - as follows:
 
  1. Status quo / laissez faire, and live with the conflicts
  2. Strict naming (including com/org) for all components, e.g.
 org.synsoft.win32.perf
  3. Strict naming (including com/org) for all components, except DMD stuff,
 which goes in phobos.xyz
  4. Semi-strict naming (excluding com/org) for all components, e.g.
 synsoft.win32.perf
  3. Semi-strict naming (including com/org) for all components, except DMD
 stuff, which goes in phobos.xyz
 
 I think that's all reasonable permutations. Please vote for the one you
 prefer. (Of course, if I've missed one, please add them numbered from 6
 onwards)
 
 I'll start: I vote 3.
 
 
 


I would recommend (what I think you ment by) 5.  That is [paraphrased]
'Semi-strict naming (excluding com/org) for all components, except D
standard library, which goes in phobos.xyz'.

I would also make the alteration that the phobos library should be
imported using 'd'; as D is no longer known as Mars, phobos no longer
makes sence. (Oh, and it saves typing).

Exampli grata:
	import d.math;
	import d.process;
	import d.thread;
	import synsoft.win32.pref;

C 2003/4/15
Apr 14 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
C wrote:

 
 Matthew Wilson wrote:

 I wanted to follow up on the earlier post by Helmut, and suggest we adopt an
 agreed module (namespace for the C++ folks; package for the Java ones)
 naming convention.

 Helmut points out quite rightly that names such as "string", "windows", etc.
 are not adequate.

 We can go the whole Java hog, and prefix everything with reversed
 namespaces, as in

     com.digitalmars.phobos.windows;
     org.synsoft.win32.perf;

 Alternatively, we can be a bit more relaxed and, at least for phobos, have
 the following

     phobos.windows.

 The other organisations could do without the org, I suppose, but I guess the
 full thing is the safest.

 So, the options are - and let's take a vote - as follows:

  1. Status quo / laissez faire, and live with the conflicts
  2. Strict naming (including com/org) for all components, e.g.
 org.synsoft.win32.perf
  3. Strict naming (including com/org) for all components, except DMD stuff,
 which goes in phobos.xyz
  4. Semi-strict naming (excluding com/org) for all components, e.g.
 synsoft.win32.perf
  3. Semi-strict naming (including com/org) for all components, except DMD
 stuff, which goes in phobos.xyz

 I think that's all reasonable permutations. Please vote for the one you
 prefer. (Of course, if I've missed one, please add them numbered from 6
 onwards)

 I'll start: I vote 3.


 
 I would recommend (what I think you ment by) 5.  That is [paraphrased]
 'Semi-strict naming (excluding com/org) for all components, except D
 standard library, which goes in phobos.xyz'.
 
 I would also make the alteration that the phobos library should be
 imported using 'd'; as D is no longer known as Mars, phobos no longer
 makes sence. (Oh, and it saves typing).
 
 Exampli grata:
         import d.math;
         import d.process;
         import d.thread;
         import synsoft.win32.pref;
 


I would prefer this one, I think this means 5.

One could do it this way:

  - Digital Mars takes these namespaces:
         import c.stdio;
         import d.thread;
         import win32.api;
         import linux.xyz;
    and any other Walter thinks to need.
       
  - Anyone is free to work in the strict namespace
         import com.google.mylib.module;
    using his domain as prefix.
         
  - Anyone may opt for a name in a namespace that has to
    be coordinated somehow (in this newsgroup; Walter):
         import synsoft.win32.pref;
         import pavel.windows;
         import deimos.xyz;
         (reserved for GPL-ed projects?)
    Using it without coordination is possible but
    risks collisions.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Apr 15 2003
parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <3E9C21CB.9AF147BB hls.via.at>, Helmut Leitner says...

C wrote:

 
 Matthew Wilson wrote:

 I wanted to follow up on the earlier post by Helmut, and suggest we adopt an
 agreed module (namespace for the C++ folks; package for the Java ones)
 naming convention.

 Helmut points out quite rightly that names such as "string", "windows", etc.
 are not adequate.

 We can go the whole Java hog, and prefix everything with reversed
 namespaces, as in

     com.digitalmars.phobos.windows;
     org.synsoft.win32.perf;

 Alternatively, we can be a bit more relaxed and, at least for phobos, have
 the following

     phobos.windows.

 The other organisations could do without the org, I suppose, but I guess the
 full thing is the safest.

 So, the options are - and let's take a vote - as follows:

  1. Status quo / laissez faire, and live with the conflicts
  2. Strict naming (including com/org) for all components, e.g.
 org.synsoft.win32.perf
  3. Strict naming (including com/org) for all components, except DMD stuff,
 which goes in phobos.xyz
  4. Semi-strict naming (excluding com/org) for all components, e.g.
 synsoft.win32.perf
  3. Semi-strict naming (including com/org) for all components, except DMD
 stuff, which goes in phobos.xyz

 I think that's all reasonable permutations. Please vote for the one you
 prefer. (Of course, if I've missed one, please add them numbered from 6
 onwards)

 I'll start: I vote 3.


 
 I would recommend (what I think you ment by) 5.  That is [paraphrased]
 'Semi-strict naming (excluding com/org) for all components, except D
 standard library, which goes in phobos.xyz'.
 
 I would also make the alteration that the phobos library should be
 imported using 'd'; as D is no longer known as Mars, phobos no longer
 makes sence. (Oh, and it saves typing).
 
 Exampli grata:
         import d.math;
         import d.process;
         import d.thread;
         import synsoft.win32.pref;
 


I would prefer this one, I think this means 5.

One could do it this way:

  - Digital Mars takes these namespaces:
         import c.stdio;
         import d.thread;
         import win32.api;
         import linux.xyz;
    and any other Walter thinks to need.
       
  - Anyone is free to work in the strict namespace
         import com.google.mylib.module;
    using his domain as prefix.
         
  - Anyone may opt for a name in a namespace that has to
    be coordinated somehow (in this newsgroup; Walter):
         import synsoft.win32.pref;
         import pavel.windows;
         import deimos.xyz;
         (reserved for GPL-ed projects?)
    Using it without coordination is possible but
    risks collisions.


I would vote this way too.  I'm a little worried about the convention of using
the domain name for the namespace.  An independent developers may not have a
domain name or domain name that would be appropriate for the namespace.
Apr 15 2003
next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Patrick Down wrote:

 I would vote this way too.  I'm a little worried about the convention of using
 the domain name for the namespace.  An independent developers may not have a
 domain name or domain name that would be appropriate for the namespace.


We could agree to create suitable parts of the namespace for this purpose, 
e. g.
    import ind.patrick.down.module;

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Apr 15 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Surely

  down.patrick.module.

But what if there're two patrick downs? I know there aren't now, but D
intends to be a widely used language, no?


"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3E9C48B4.AAF5391B chello.at...

 Patrick Down wrote:

 I would vote this way too.  I'm a little worried about the convention of




using

 the domain name for the namespace.  An independent developers may not




have a

 domain name or domain name that would be appropriate for the namespace.


 We could agree to create suitable parts of the namespace for this purpose,
 e. g.
     import ind.patrick.down.module;

 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com
Apr 15 2003
parent Patrick Down <Patrick_member pathlink.com> writes:
In article <b7hqpo$1cgo$1 digitaldaemon.com>, Matthew Wilson says...

Surely

  down.patrick.module.

But what if there're two patrick downs? I know there aren't now, but D
intends to be a widely used language, no?


"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3E9C48B4.AAF5391B chello.at...

 Patrick Down wrote:

 I would vote this way too.  I'm a little worried about the convention of




using

 the domain name for the namespace.  An independent developers may not




have a

 domain name or domain name that would be appropriate for the namespace.


 We could agree to create suitable parts of the namespace for this purpose,
 e. g.
     import ind.patrick.down.module;

 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com




I think even independant developer(s) might like to
use an alias rather than a name. 

How about this:

1. com. and org. means a registered domain name.

import com.codemoon.glud.winbase;

2. ind. means a some loosely managed namespace.

import ind.billandted.ftp;

3. phobos gets to use the top level namespace and
other popular modules can get voted in if requested.
Apr 15 2003
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
I would vote this way too.  I'm a little worried about the convention of using
the domain name for the namespace.  An independent developers may not have a
domain name or domain name that would be appropriate for the namespace.  


totally agree, companies come and go (along with their domain name), the
internet domain naming stuff is very weak
Apr 15 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Yes, that's a good point. The upside, however, is that it provides
uniqueness.

However, I guess if it's a collegial approach to naming - which can be as
simply as suggesting a module base name on the newsgroup and waiting for the
flak - then we should be able to work around the lack of absolute
uniqueness.

The downside to this freer approach is that names would be inconsistent,
which would mean either remembering them, or wasting time looking for them.
Hence, there would have to be some agreed convention. Suggestions, please,
everyone.

Another approach would be to use a UUID for the module name, such as

  import F4E600DD_72CE_4576_8327_17F25C1773A3.win32.gdi;




"Mark T" <Mark_member pathlink.com> wrote in message
news:b7i6i9$1kjb$1 digitaldaemon.com...

I would vote this way too.  I'm a little worried about the convention of




using

the domain name for the namespace.  An independent developers may not




have a

domain name or domain name that would be appropriate for the namespace.


 totally agree, companies come and go (along with their domain name), the
 internet domain naming stuff is very weak
Apr 15 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
I vote 4.  com and org don't add much useful info to the name.  i.e. the
odds of a collision due to foo.org writing a D module that conflicts with
foo.com's D module is exceedingly low.  Consistency is better than
non-consistency so I don't think Phobos deserves special treatment;  au
contraire it should set the example.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b7gslg$2pp9$1 digitaldaemon.com...

 I wanted to follow up on the earlier post by Helmut, and suggest we adopt


an

 agreed module (namespace for the C++ folks; package for the Java ones)
 naming convention.

 Helmut points out quite rightly that names such as "string", "windows",


etc.

 are not adequate.

 We can go the whole Java hog, and prefix everything with reversed
 namespaces, as in

     com.digitalmars.phobos.windows;
     org.synsoft.win32.perf;

 Alternatively, we can be a bit more relaxed and, at least for phobos, have
 the following

     phobos.windows.

 The other organisations could do without the org, I suppose, but I guess


the

 full thing is the safest.

 So, the options are - and let's take a vote - as follows:

  1. Status quo / laissez faire, and live with the conflicts
  2. Strict naming (including com/org) for all components, e.g.
 org.synsoft.win32.perf
  3. Strict naming (including com/org) for all components, except DMD


stuff,

 which goes in phobos.xyz
  4. Semi-strict naming (excluding com/org) for all components, e.g.
 synsoft.win32.perf
  3. Semi-strict naming (including com/org) for all components, except DMD
 stuff, which goes in phobos.xyz

 I think that's all reasonable permutations. Please vote for the one you
 prefer. (Of course, if I've missed one, please add them numbered from 6
 onwards)

 I'll start: I vote 3.
Apr 15 2003
prev sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
Yes, please avoid the domain names.

Besides that unnatural binding, there is actually _no need_
for globally unique names. What's needed is avoiding clashes,
but that does not require a global hierarchy.

1. Add a prefix (like "d", as someone suggested) for the
standard lib, meaning:

    "Sorry, I reserve this one subtree of the global space,
    to ensure a standard base layout for every installation
    -- Walter" ;)

2. Non-standard packages, OTOH, don't need a standard layout
-- exactly because they are non-standard...

3. Collisions are a project-specific issue of combining
non-standard packages in a conflicting way.

4. That has to be addressed on the project-level. One clean
way is importing a conflicting package into a "sandbox",
using a prefix. (Is the C++ way applicable to D?)


Cheers,
Sz.
Apr 17 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Yes, please avoid the domain names.


Have no problem with that


 Besides that unnatural binding, there is actually _no need_
 for globally unique names. What's needed is avoiding clashes,
 but that does not require a global hierarchy.

 1. Add a prefix (like "d", as someone suggested) for the
 standard lib, meaning:

     "Sorry, I reserve this one subtree of the global space,
     to ensure a standard base layout for every installation
     -- Walter" ;)


Totally agree with this. Why is it not done consistently already?


 2. Non-standard packages, OTOH, don't need a standard layout
 -- exactly because they are non-standard...

 3. Collisions are a project-specific issue of combining
 non-standard packages in a conflicting way.


So you're arguing for the status quo - with which people are already having
problems.

Why not just forget about packages and uniquness and just declare everything
globally?


 4. That has to be addressed on the project-level. One clean
 way is importing a conflicting package into a "sandbox",
 using a prefix. (Is the C++ way applicable to D?)


Why not come up with a convention that works, and save us all a huge amount
of totally pointless effort?
Apr 17 2003
next sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:b7njkc$1gv3$1 digitaldaemon.com...

 3. Collisions are a project-specific issue of combining
 non-standard packages in a conflicting way.


 So you're arguing for the status quo - with which people are already


having

 problems.


No, I don't think I do.


 Why not just forget about packages and uniquness and just declare


everything

 globally?


Because that would be a bit stupid, Matt. ;)

_Within a project_, you need a hieararchy. You need to
design and maintain _your own_ hierarchical namespace.
But not the whole world. See now? There *is* life between
a totally flat global namespace and a single global tree.
Both extremes are suboptimal.


 4. That has to be addressed on the project-level. One clean
 way is importing a conflicting package into a "sandbox",
 using a prefix. (Is the C++ way applicable to D?)


 Why not come up with a convention that works, and save us all a huge


amount

 of totally pointless effort?


(Sorry, do I correctly sense unnecessary emotions here?...)

Cheers,
Sz.
Apr 17 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 3. Collisions are a project-specific issue of combining
 non-standard packages in a conflicting way.


 So you're arguing for the status quo - with which people are already


 having

 problems.


 No, I don't think I do.


Then I need a more fulsome explanation, as that's how it appears.


 Why not just forget about packages and uniquness and just declare


 everything

 globally?


 Because that would be a bit stupid, Matt. ;)


That was sarcasm, as, presumably, your response is. Either or both of us
should probably drop that, as it is misunderstood all too readily. Sorry.


 _Within a project_, you need a hieararchy. You need to
 design and maintain _your own_ hierarchical namespace.
 But not the whole world. See now? There *is* life between
 a totally flat global namespace and a single global tree.
 Both extremes are suboptimal.


You'd need to give me examples. Without them it seems you are proposing a
laissez faire approach which is already causing problems and is _guaranteed_
to cause big problems in the future. It happens in C++, it happens in .NET
and it even happens in Java, despite their best attempts. (Though it's
mostly caused in Java by the use of the evil "import *;")

Since I'm anything but imaginative and am, for want of a better description,
a pragmatist, I'll go for the strictest mechanism possible, simply because
maintenance costs are always the most significant. If people disagree with
that, as is both their right and wont, then they need to propose something
workable - dare I say "professional" - or accept that they're going to have
to make a few more key-presses.


 4. That has to be addressed on the project-level. One clean
 way is importing a conflicting package into a "sandbox",
 using a prefix. (Is the C++ way applicable to D?)


 Why not come up with a convention that works, and save us all a huge


 amount

 of totally pointless effort?


 (Sorry, do I correctly sense unnecessary emotions here?...)


I understood this to be you suggesting that we can wrap conflicting
symbols/modules inside proprietary modules that serve only to disambiguate
clashes, in the same way that one has to, for example, wrap the otherwise
well-written ZLib in an API simply because it takes too many liberties with
the global namespace.

If that was not what you were suggesting - which would be workable, but
tedious (hence my "save us all a huge amount of totally pointless effort") -
then I retract my comment, and reserve judgment until I understand what you
do mean.


Sorry if I've been short on this - and it was not directed at any
individual - but I just find debates based upon people wanting to type fewer
characters in exchange for dumping large amounts of robustness, flexibility
and clarity very perplexing and not a little annoying. I thought the point
of D is to become a serious contender in the real - and that is to say,
whether we like it or not, the business world - and not just be a toy or
hobby; at least that's what I've been led to believe.

Spleen at 0. Fire at will.

Matthew
Apr 17 2003
prev sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 4. That has to be addressed on the project-level. One clean
 way is importing a conflicting package into a "sandbox",
 using a prefix. (Is the C++ way applicable to D?)


 Why not come up with a convention that works, and save us all a huge


amount

 of totally pointless effort?


Sorry, I'm too tired now for that. I've just finished
porting the fresh Lua 5.0 API to D and I need a looong
sleep.

Someone who is also familiar with the C++ namespaces
_and_ much more familiar with D than I am, _and_ is
not so exhausted as I am now _and_ understands my point,
would be in a much better position for coming up with
a usable syntax than me.

Think of something along this idea:

//--- std. stuff
import d.stuff;    // all clear

//--- conflicting stuff 1
import badname;
//imort badname;  // another package with the same name; no way...
import badname as goodname;    // now its fine

//--- conflicting stuff 2
imort package1;    // imports 'badname'
//imort package2;  // would import its own 'badname'
import package2 as xxx.package2;   // now it would import
                                   // its own 'badname' as xxx.badname;

Cannot keep awake now, sorry...

Good luck,
Sz.
Apr 17 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
An omission:


 //--- conflicting stuff 1
 import badname;
 //imort badname;  // another package with the same name; no way...
 import badname as goodname;    // now its fine


Could make sense this way, perhaps:


 //--- conflicting stuff 1
 import badname;
 //imort badname;  // no way
 import some/path/to/another/badname as goodname;    // OK


(But I'm really not familiar enough with the current
D mechanism -- this is why I wanted to leave the details
for the more knowledgeable.)

Good night (soon morning here),
Sz.
Apr 17 2003
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
 //--- conflicting stuff 1
 import badname;
 //imort badname;  // no way
 import some/path/to/another/badname as goodname;    // OK




Back in school when I had to "invent" a fake language as part of a project,
I actually had something like this.. I think the syntax was more along the
lines of:
   include std/utils/collection/vector   libVector;

This would have included the 'std/utils/collection/vector' library, with its
namespace set to 'libVector'... which I guess is kind of obvious.
Personally though, I rather like the idea of using 'as' to do this, rather
than my old   syntax from around 1998 or so.  :)

As to the module-naming issue, I vote for semi-strict names with phobos
top-level and renamed to d.
As to the issue of how the names should be formed... you got me.

--C. Sauls
Apr 19 2003
parent "Thomas D. Marsh" <thomas.marsh seznam.cz> writes:
This is reminiscent of Python's import syntax:

        import sys

        def quitter():


Example 2:

        from sys import exit

        def quiter():


Basically, what you import is what you get. If you say "import foo.bar.X"
then you have to prefix everything by "foo.bar.X", whereas "from foo.bar.X
import Y", then you can use Y directly.

Certainly helps to control conflicts. Then again, in python conflicts during
import just overwrite the namespace. In a compiler such as the D language
they should issue an error and abort compilation.

--thomas

C. Sauls wrote:


 //--- conflicting stuff 1
 import badname;
 //imort badname;  // no way
 import some/path/to/another/badname as goodname;    // OK




 
 Back in school when I had to "invent" a fake language as part of a
 project, I actually had something like this.. I think the syntax was more
 along the lines of:
    include std/utils/collection/vector   libVector;
 
 This would have included the 'std/utils/collection/vector' library, with
 its namespace set to 'libVector'... which I guess is kind of obvious.
 Personally though, I rather like the idea of using 'as' to do this, rather
 than my old   syntax from around 1998 or so.  :)
 
 As to the module-naming issue, I vote for semi-strict names with phobos
 top-level and renamed to d.
 As to the issue of how the names should be formed... you got me.
 
 --C. Sauls


-- 
"Paul Lynde to block..."
-- a contestant on "Hollywood Squares"
Apr 25 2003