Thread overview | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 15, 2003 Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
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. |
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | Vote for: 3 I think it is most reasonable. Nic Tiger. |
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | 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
|
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to C | 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 |
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | 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. > > > |
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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. |
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Down |
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
|
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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 |
April 15, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | 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. |
April 16, 2003 Re: Modules (namespaces) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Down | >
>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
|
Copyright © 1999-2021 by the D Language Foundation