In article <bjpdn4$241a$2@digitaldaemon.com>, Riccardo De Agostini says...
>
>"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjp6oc$1pie$1@digitaldaemon.com...
>> [...] If we like
>>
>>   org.blah.lib-main.lib-individual.*
>>   com.digitalmars.phobos.
>>
>> isn't putting everything into
>>
>>   com.XXXXX.*
>>
>> utterly pointless, since everything will just have com.XXXXX in front of
>it.
>
>That could in fact make less people willing to host their projects on the repository site.There are companies which release open source code; I don't think they'd go with anything else than com.companyname for their libraries. They spend money on it, leave them the glory at least. :)

The point is that library authors *could* use the com.XXXXX prefix for their libraries, guarunteeing them a unique canonical name. However, there's no need to impose that type of naming convention on them if they already have a domain name of their own. I agree that it would be pointless to have everything reside under the com.XXXXX structure. I'm just saying that I'll make sure those project names are unique so that the package names are also unique.

I also don't think there's anything special about internet domain names, except that they're canonical, by definition. I think that's the only reason that they're used as package names in Java (AFAIK, there is no auto-downloading feature for classes in Java).

If we don't use domain names as package name prefixes, how do you suggest we gauruntee unique package names? I'd hate to have to download a package from 'name.johnsmith.*' and not know that the "johnsmith" name is gaurunteed to be unique. Of course, I don't really care about the domain names themselves, so if you can think of another system that gauruntees unique canonical names, I'd like to hear it. And I'm not crazy about the idea of using my repository site as a registrar of package names. But you might be able to convince me. Maybe.

--Benji Smith

Benji Smith wrote:
> If we don't use domain names as package name prefixes, how do you suggest we gauruntee unique package names? I'd hate to have to download a package from 'name.johnsmith.*' and not know that the "johnsmith" name is gaurunteed to be unique.

While I see your point, I can't agree. The chance for such a collision is small (always in mind that the typical coding will be done using correct domain names).

Anyway your system will have to accept the given domain names without a chance to check them. So I suppose anyone could check in a "com.acorp.module" without being the owner of the domain "acorp.com" and you wouldn't even notice it.

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

In article <3F608254.36C58B20@hls.via.at>, Helmut Leitner says...
>Anyway your system will have to accept the given domain names without a chance to check them. So I suppose anyone could check in a "com.acorp.module" without being the owner of the domain "acorp.com" and you wouldn't even notice it.

Yes. For example, it seems as though Burton Radons, who is currently using the prefix 'net.BurtonRadons' for his dig packages, doesn't actually own the domain name 'burtonradons.net'. I think that's a mistake on his part. I think that if he's writing code using that prefix, it implies that you can visit www.burtonradons.net for more information about the packages. In this case, that's not true.

So the domain name convention provide any mechanism for guarunteeing that people only write code for their own domains. In fact, I could write java code and call my packages 'com.sun.java.blingblang'. If I do so, I have to hope that Sun will never release a package called 'blingblang'. If they do, I'm the one who will have to change my package name, since they're the domain owners.

I know that namespace conlicts will be rare, no matter what naming convention we use, but at some point, there will be a few conflicts (if we get to the point where there is an active library-development community (and we're all hoping for that)). Using a domain-name-based package-naming convention, we'll have some way of figure out how to resolve those conflicts. But maybe there's a better convention we can use. If you have any ideas, I want to hear them.

--Benji

"Ilya Minkov" <minkov@cs.tum.edu> ha scritto nel messaggio news:bjprc8$2lk3$1@digitaldaemon.com...
>   - There is only one repository site.

...which, at this point, would also serve as namespace registrar, right? Benji said he doesn't love the idea much, but it makes a lot of sense.

>   - Project names *are* namespace names. No "com.blahblah" in front;

I'd leave developers with the possibility of prepending the developer name,
as in "burtonradons.yetanotherlib" instead of just "yetanotherlib" if Burton
so wishes. I'm not with the Internet domain idea, definitely.
Of course I'm not ever releasing anything called "riccardodeagostini.mylib",
or rewriting the library could take less time than typing the imports... :)

> I can't recall any name collision when using Delphi, even though it uses next to no namespace protection.

Me neither. Though people like TurboPower have always used two-letter prefixes on all their units' names...

> PS. Ricardo: you do not need to register components with the IDE just to make Delphi compile some project which uses them. :) Just show it the path and it shall figure out. :) Much less pain than i'm having with C++, which relies on the actual file positions, almost manual linking, and so on...

Granted, Delphi is not the worst case. But I don't even want to show it the path, call me lazy! :) I want a single setting (or environment variable) a la CLASSPATH. I want to be able to just copy the entire "classpath" tree to my new development box and have it working at once. I want to be able to use a classpath (in lack, for now, of a better name) on a network share. OK, maybe I want too much, but I tried... :)

Ric

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:bjosk1$1aut$1@digitaldaemon.com...
> I have recently finished compiling the zillion or so different software
packages
> that will be needed to host the new D source-code repository site. Along
the

Incredible work Benji. I know I'll be using your services a lot. I read this newsgroup almost dayly but don't get into the discussions too often. But this kind of donation to the comunity surely deserves congratulations from everyone here.



> I'd like to avoid this type of mayhem in the D community by establishing a standard location for source code, libraries, and include files.

A standard location for D source code it's a really good idea. Java's naming convention for packages it's a little clumsy but works pretty well. As Ricardo said, there's no need to add com. or net. to module names in D and probably add a lot of collisions with variable names:


import com.digitalmars.win32;

void main()
{
    ComObject com = new ComObject();
    com.AddRef();
}

test.d(7): undefined identifier module com.AddRef


I think module names should be MixedCase and prepending the name of the company or organization that is mantaining it, except of course for the standard library wich should be D:

import D;    // implicitly imported.
import D.Win32;
import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
import Microsoft.ADO;
import Eclipse.SWT.Widgets;

And for independent developers we should decide on a standard module that will be open for them:

import Contrib.BurtonRadons.DIG;
import Contrib.JulioCesarCarrascal.SomeLib;


It can be "Contrib", "Personal", "Name", etc. I don't mind as long as it is reserved for that use.

I totally aggree with this option, I dont like the com / org prefix, but a company/ organization name prefix seems to work beautifully.  I also vote for the Contrib, though JulioCesarCarrascal is a lot of typing and easy to get wrong!

Charles


"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:bjq5f6$2fd$1@digitaldaemon.com...
>
> "Benji Smith" <dlanguage@xxagg.com> wrote in message news:bjosk1$1aut$1@digitaldaemon.com...
> > I have recently finished compiling the zillion or so different software
> packages
> > that will be needed to host the new D source-code repository site. Along
> the
>
> Incredible work Benji. I know I'll be using your services a lot. I read
this
> newsgroup almost dayly but don't get into the discussions too often. But this kind of donation to the comunity surely deserves congratulations from everyone here.
>
>
>
> > I'd like to avoid this type of mayhem in the D community by establishing
a
> > standard location for source code, libraries, and include files.
>
> A standard location for D source code it's a really good idea. Java's
naming
> convention for packages it's a little clumsy but works pretty well. As Ricardo said, there's no need to add com. or net. to module names in D and probably add a lot of collisions with variable names:
>
>
> import com.digitalmars.win32;
>
> void main()
> {
>     ComObject com = new ComObject();
>     com.AddRef();
> }
>
> test.d(7): undefined identifier module com.AddRef
>
>
> I think module names should be MixedCase and prepending the name of the company or organization that is mantaining it, except of course for the standard library wich should be D:
>
> import D;    // implicitly imported.
> import D.Win32;
> import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
> import Microsoft.ADO;
> import Eclipse.SWT.Widgets;
>
> And for independent developers we should decide on a standard module that will be open for them:
>
> import Contrib.BurtonRadons.DIG;
> import Contrib.JulioCesarCarrascal.SomeLib;
>
>
> It can be "Contrib", "Personal", "Name", etc. I don't mind as long as it
is
> reserved for that use.
>
>
>
>

Riccardo De Agostini wrote:
>>  - There is only one repository site.
> 
> ...which, at this point, would also serve as namespace registrar, right?
> Benji said he doesn't love the idea much, but it makes a lot of sense.

Exactly!

Now i have gotten second thoughts. The official name registration facility may be at Walter's or Jan's site - it should be free and voluntary, but everyone should do it when releasing an open-source library to the world...

The world need not be limited to one repository - but the repositories would need to co-operate on giving away project names.

It just seems to me that if there is a central repository, there isn't much sense to make its project fall into such a deep namespace... They can be top-level if the obvious names can be reserved.

>>  - Project names *are* namespace names. No "com.blahblah" in front;
> 
> I'd leave developers with the possibility of prepending the developer name,
> as in "burtonradons.yetanotherlib" instead of just "yetanotherlib" if Burton
> so wishes. I'm not with the Internet domain idea, definitely.

yeah, if he has registered a project of his name. :)

But well, the idea with domains is not bad for people who do not want to
be dependant on the central registration service... but want to have
net, com, org, or whatever in the beginning of their unit names. This way should be open to them, and having a top-level domain name in the beginning would clearly disambiguate them from anything else.

This all leads to a possible necessity to make it possible to register
sub-projects... This is probably not important at first, but later it
could be good. The projects would get a dot in their name and would be
acessible as

subproject.project.XXXXX.com
www.XXXXX.com/projects/project.subproject

but for the first the members should simply arrange directories in their
webspace to match sub-project names.

www.XXXXX.com/projects/project/subproject
project.XXXXX.com/subproject

> Me neither. Though people like TurboPower have always used two-letter
> prefixes on all their units' names...

Ah, that's the reason. :) Besides, important libs were well known and
noone would dare to invent a colliding name. :)

> Granted, Delphi is not the worst case. But I don't even want to show it the
> path, call me lazy! :) I want a single setting (or environment variable) a
> la CLASSPATH.

The only thing that lacked there was a recursive search of
sub-directories which would eliminate the problem completely. :) Plus a
possibility to exclude a certain directory from search by putting a flag
file into it. :)

There is a deep ocean to similar things. Like, with most windows
proggies - you move it and it breaks. And later it should not be able to
uninstall itself. Thus reorganising software is bound to go through pain
of uninstall- reinstall- reconfigure... Unlike on a mac - move and it
picks on. Even on another computer. That's how everything should work -
including compilers. :)))))) This imposes another problem within
multi-user environmants but i have figured out a solution as well ;) ...
Gotta tell it the Yellow Tab (BeOS/Zeta) crew before it's too late. :)

-eye

"Benji Smith" <dlanguage@xxagg.com> escreveu na mensagem news:bjosk1$1aut$1@digitaldaemon.com...

[snip]

Using a single source tree has a couple of problems.

First it won't help with different versions of source code, so if I have to use version 0.3.5 of dig with dcc 1.2, but dTree 1.0.2 uses dig 0.2.4 I'll have to place both versions somewhere in the tree. I had this problem in Java once (particularly nasty when you consider different versions of JDK break different libraries in different ways). Also installing newer versions will be more fun: instead of just installing a new version under a dlib1.0.3 folder he'll have to remember which were the old modules and delete them before, in the case the project splitted a single module in two (somewhat common).

Second it's hard to keep track of dependencies. If we have the Java model and look at Apache we'll see lots of code under the org.apache tree, but some pieces are from xml (e.g. xerces and xalan) other from jakarta (e.g. bcel, tomcat) all from different projects with different maintainers. Also they keep different branches sometimes (Xerces has two active releases IIRC). It's very difficult to keep track of everything, from maintainers rights to versioning if everything falls under the same tree inside the cvs, so they keep different projects inside the cvs and everything is fine. But if the user has to maintain everything in a single source he won't be able to keep track over things using cvs (i.e. the tree org.apache will be shared in his box but separated in the server), so he'll probably maintain things that he update from cvs outside the released trees.

I like the idea of a single source tree, but it doesn't work with the filesystems we have. If we had a filesystem aware of library versions and able to distinguish two projects that live under the same tree it would be easier.

<wishful-thinking>
Someone ;) mentioned a virtual filesystem project earlier for D, perhaps we
could modify this idea and come with a D library manager (DLM): new
libraries are downloaded in compressed form (using a standard D installer
creating an executable binary) and installed in the DLM location. During the
installation the DLM becomes aware of the library version and dependencies,
so it'll be able to keep it in a separated fisical location, but logically
connected to the other modules (including versioning conflicts, etc.).
During compilation the DLM can offer the real path to the compiler, so we
just can "dlmc <my_project>" and it'll call the registered compiler with the
appropriate paths. It would handle dll versioning too and clean our houses
;)
</wishful-thinking>

BTW, the repository site idea is very good, but I don't think every project must be named after a domain name, specially the domain name of the site. D standard libraries should be under "d" and specific projects should be under their own module names (e.g. dtlsoft). IMHO using domain names is wrong because they put all "org.*" under the same logical tree even if they have no connection.

    Best regards,
    Daniel Yokomiso.

"The consumer is not an idiot, she is your wife."
 - David Ogilvy, founder of Ogilvy & Mather


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> ha scritto nel messaggio news:bjq5f6$2fd$1@digitaldaemon.com...
> I think module names should be MixedCase and prepending the name of the company or organization that is mantaining it, except of course for the standard library wich should be D:
>
> import D;    // implicitly imported.
> import D.Win32;
> import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
> import Microsoft.ADO;
> import Eclipse.SWT.Widgets;

I'm with you on the name hierarchy, but I'd stick to lower case only.

> And for independent developers we should decide on a standard module that will be open for them:
>
> import Contrib.BurtonRadons.DIG;
> import Contrib.JulioCesarCarrascal.SomeLib;

Why not let Burton, or yourself, have his own top level namespace? Hasn't an independent developer the same dignity as a corporation?

Ric

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> ha scritto nel messaggio news:bjr3nu$1cjr$1@digitaldaemon.com...
> First it won't help with different versions of source code, so if I have
to
> use version 0.3.5 of dig with dcc 1.2, but dTree 1.0.2 uses dig 0.2.4 I'll have to place both versions somewhere in the tree. I had this problem in Java once (particularly nasty when you consider different versions of JDK break different libraries in different ways). Also installing newer
versions
> will be more fun: instead of just installing a new version under a
dlib1.0.3
> folder he'll have to remember which were the old modules and delete them before, in the case the project splitted a single module in two (somewhat common).

<daydreaming>

-----<in myprog.d>-----
import stlsoft.vector version 2.0;

-----<in vector.d>------

version 2.2 compatible 2.0;

-----<in other words...>-----

How about automatic version checking by the compiler?

<daydreaming>

(This time Walter is going to ban me from the ng :-) )

Ric