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


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


 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


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


 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


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


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

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

 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

 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

 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

 problems.

No, I don't think I do.
 Why not just forget about packages and uniquness and just declare

 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

 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

 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

 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

 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

 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():
                sys.exit()      # have to explicitly specify sys.*

Example 2:

        from sys import exit

        def quiter():
                exit()          # we imported the symbol directly

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