Riccardo De Agostini wrote:
> 
> "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?

It wouldn't be funny to have a top level domain directrory with hundreds of entries, somewhere in between, hard to find, "d", "org" and "com" where the music really plays.

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

Helmut Leitner wrote:

> It wouldn't be funny to have a top level domain directrory with hundreds of entries, somewhere in between, hard to find, "d", "org" and "com" where the music really plays.

I frankly can't see what the problem would be. Would you please explain what you mean?

-eye

Ilya Minkov wrote:
> 
> Helmut Leitner wrote:
> 
> > It wouldn't be funny to have a top level domain directrory with hundreds of entries, somewhere in between, hard to find, "d", "org" and "com" where the music really plays.
> 
> I frankly can't see what the problem would be. Would you please explain what you mean?

There is no problem, its just aestetical. A top level like

  ROOT/c
      /com
      /d
      /name
      /net
      /org

would just look better to me than having hundreds of entries at this level.

It would also be easier to select a semantical part of it like e. g.

      /c
      /d
      /org

for updating.

And I think that the Java-like domain type organization is basically a good way to go, just not in the strict sense that forces phobos into

      /com/digitalmars/phobos

Just my $0.02.

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

Daniel Yokomiso wrote:
> <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>

Operating systems should allow to make directories mirror other directories. When you look into this directory(1), you see files which are actually in another directory(2), plus the files in (1). If the file with the same name exists in both, you see the one in (1). However, whenever you try to write or modify files through (1) - the changes should be written in (1) even if the original file was in (2).

This simple magic allows to write programs which would store their configuration in their directory, that is the way single-user systems work. In the multi-user environment, an administrator would install bunches of software on some common read-only storage. If a sertain user wants to use some piece of software, he simply creates a directory for it in his space - wherever he wants - and lets it mirror the actual location, which may be read-only... and it works rightaway.

I don't know whether any OS already implements such a thing or not, but i believe it would be of a lot of help in all cases, where configurations need to be slightly different and directory structures clean... There must also be some way to hide files in a mirror...

Don't know whether this particular idea of mine expands to library version control, and it doefinately doesn't expand to some operating systems... So your idea is good anyway.

Lunatic mentioned a virual filesystem which would work on associated words, instead of directores. But it wasn't related to D.

-eye

This sounds like what I do with search lists on OpenVMS...
One can define a logical name that actually points to a list of directories.

Something like:
define appdir "appdisk:[app] , usrdisk:[me.app]"
(I've forgotten the exact syntax in the year-and-a-half I've been away from
OpenVMS.)

Now I can use:
dir appdir
and see both directories.

I can also:
set default appdir
("set default" is "change directory")

And I can say that my config file (or data or whatever) is appdir:app.cfg

Now, if I'm a new user with no personal config file, I get the shared one from the appdisk, if I already have a config file it will be found in my directory, and when I save the file it gets saved in my directory for future use.

I used this quite a bit when programming on OpenVMS. For each project I had a WORK and a CLEAN directory with a search list containing them (in that order). I would fetch code from CMS (CVS) into the CLEAN directory. Then I could look at the file and if I modified it it would be saved into the WORK directory. Then I could send only the files in WORK back to CMS.

This sort of thing also simplifies builds, you don't need to have everything in one physical directory, you don't need to add a whole ton of directories to your include and library switches. And you can have any intermediate files be created away from the source code.

OpenVMS' logicals are perhaps the most powerful feature of the OS and yet no other OS uses them? They're way better than logical link files.

I'll also add that OpenVMS has the ability to have multiple names for a directory or file (which is dangerous and seldom used).

In article <bjt4bc$14ig$1@digitaldaemon.com>, Ilya Minkov says...
>
>Daniel Yokomiso wrote:
>> <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>
>
>Operating systems should allow to make directories mirror other directories. When you look into this directory(1), you see files which are actually in another directory(2), plus the files in (1). If the file with the same name exists in both, you see the one in (1). However, whenever you try to write or modify files through (1) - the changes should be written in (1) even if the original file was in (2).
>
>This simple magic allows to write programs which would store their configuration in their directory, that is the way single-user systems work. In the multi-user environment, an administrator would install bunches of software on some common read-only storage. If a sertain user wants to use some piece of software, he simply creates a directory for it in his space - wherever he wants - and lets it mirror the actual location, which may be read-only... and it works rightaway.
>
>I don't know whether any OS already implements such a thing or not, but i believe it would be of a lot of help in all cases, where configurations need to be slightly different and directory structures clean... There must also be some way to hide files in a mirror...
>
>Don't know whether this particular idea of mine expands to library version control, and it doefinately doesn't expand to some operating systems... So your idea is good anyway.
>
>Lunatic mentioned a virual filesystem which would work on associated words, instead of directores. But it wasn't related to D.
>
>-eye
>

John Boucher
The King had Humpty pushed.

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message
news:bjq5f6$2fd$1@digitaldaemon.com...
| ...
| 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;
|

As Charles said, writing a whole name could be very prone to errors (just a sample: this is copied and pasted because I still don't know how to write it: Achilleas Margaritis... well, we live in a world with a lot of diversity).

However I really like the contrib part, for what my vote counts.

But I don't think we should use people's names. I don't see the need. Sure, it's good to give credit to the creator, but I think it could envolve too much complexity. Maybe it could be better if somewhere was maintained a central library names repository (was it already proposed? I think so). I'm mixing things, but think about this:

import contrib.DanielYokomiso.deimos;
import contrib.[SorryIForgotThePerson].deimos;

The first one is a template library. The second one is to convert .h files to d modules. Now, someone new comes and sees that, he won't know what to do because both things have the same name (ok, the second one isn't a library, but you get the point). The point is to avoid name duplication. So Benji could do that at first (register names), and later someone else could (I dunno... maybe there'll be an International D Organization where those things could be ruled).

[Sometimes I tend to talk too much and not say much, mix ideas... But that's pretty much what's in my mind about this]

————————————————————————— Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.516 / Virus Database: 313 - Release Date: 2003-09-01

Carlos Santander wrote:
> But I don't think we should use people's names. I don't see the need.
Sure,
> it's good to give credit to the creator, but I think it could envolve too much complexity. Maybe it could be better if somewhere was maintained a

Yes, names from other countries can be difficult to write but if if we drop developer name's there's a problem that I'll try to explain better (I'm wrestling with my poor english).


> import contrib.DanielYokomiso.deimos;
> import contrib.[SorryIForgotThePerson].deimos;
>
> The first one is a template library. The second one is to convert .h files to d modules. Now, someone new comes and sees that, he won't know what to
do

What if some of us wanted to re-implement the standard XML library? We could easly choose one of the following:

import D.XML;
import Contrib.JulioCesarCarrascal.XML;
import Contrib.DanielYokomiso.XML;
import Contrib.CarlosSantander.XML;

And, as long each one implemented the same public interface, the code using the library will work fine. I'm bringing this up is because the first implementation almost always isn't the fastest or the smallest and people will prefer Daniel's XML library.


> dunno... maybe there'll be an International D Organization where those things could be ruled).

Maybe an "International D Organization" it's a political overkill for an issue that could be solved with just a good naming convention for module names.

Also, I vote for mixed-case names so we can avoid name collisions with variables. Modules look a lot more like classes than variables. That's why I think lower-case names for modules is inconsistent.



> [Sometimes I tend to talk too much and not say much, mix ideas... But
that's
> pretty much what's in my mind about this]

Me too. I'm thinking to go back to the domain name thing and drop the whole issue  :)

In article <bjvc01$19bv$2@digitaldaemon.com>, Julio César Carrascal Urquijo says...
>> dunno... maybe there'll be an International D Organization where those things could be ruled).
>
>Maybe an "International D Organization" it's a political overkill for an issue that could be solved with just a good naming convention for module names.

Howsabout "D Organization of Heuristics" AKA "D'OH!"

>
>Also, I vote for mixed-case names so we can avoid name collisions with variables. Modules look a lot more like classes than variables. That's why I think lower-case names for modules is inconsistent.
>
>
>

As an unrepentant OpenVMS guy I don't like case sensitivity in file systems. What if a D compiler is ever ported to OpenVMS? (As if!)

John Boucher
The King had Humpty pushed.

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> escreveu na mensagem news:bjvc01$19bv$2@digitaldaemon.com...
>
> Carlos Santander wrote:

[snip]

> > import contrib.DanielYokomiso.deimos;
> > import contrib.[SorryIForgotThePerson].deimos;


[snip]

> import D.XML;
> import Contrib.JulioCesarCarrascal.XML;
> import Contrib.DanielYokomiso.XML;
> import Contrib.CarlosSantander.XML;

Am I becoming famous? Must be, now I'm an code example ;)


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 1/9/2003

In article <bjs2et$2o89$1@digitaldaemon.com>, Riccardo De Agostini wrote:
> "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 :-) )

I hope not, but the issue is not very simple.

Having two different versions in the source tree (and being able to pick one in an "import" sentence) would be a rather useful feature. Look at the difficulty that one has to go through to compile a project that has 15 libraries it depends on. If all the libraries are under development and break all the time, hell breaks loose. (Ever tried to compile GNOME on Linux?)

The fundamental thing is:

I want to be confident that when upgrading SomeProject from 1.0 to 1.1 the former version won't be overwritten and all software that depends on version 1.0 can be still compiled and used as if nothing had happened.

You might want also to say something like

import stlsoft.vector version >=2.0;

or

import dot.com.boom.bang.xml version 1.0 .. 1.2;

(now would that mean 1.0 <= version < 1.2 or 1.0 <= version <= 1.2...)

More things to think about... How do you compare version numbers, for example? There are plenty of different version number schemes, starting from simple x.y.z where x, y and z are numbers, to something like 1.0445j and 2.0-pre4. And you might have branches that are indicated in the version number (Linux kernel has branched versions such as 2.4.21-pre5-ac3, but that kind of versioning might be out of scale here)

-Antti