I was napping with my wife today, and as I woke, I had a wild thought. Importing modules only based on filenames is *extremely* restrictive. It prevents having multiple versions of a library installed on a machine, and it practically begs for trouble where people have different modules with the same file name.  Thus, I think that module names should be defined by strings and version numbers.  An import would then come of the form:

import "Standard D Library: math" 1.3;

Version numbers, if given, specify a minimum.  The compiler would import the highest version number module it can find in the search path; if it cannot find one at least as high as required, a build error is reported.  The version number could be ommitted, meaning that any version would be accepted:

import "Standard D Library: math";

The modules would then have to have some way to declare their name, perhaps with the export keyword:

export "Standard D Library: math" 1.67;

If you don't export a name, then your module name would default to the filename, version 1.0.

To avoid parsing hundreds of files at once, I would suggest that libraries would include some sort of lookup database file.

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B7F3E7E.C9766FC5@deming-os.org...
> I was napping with my wife today, and as I woke, I had a wild thought. Importing modules only based on filenames is *extremely* restrictive. It prevents having multiple versions of a library installed on a machine, and it practically begs for trouble where people have different modules with the same file name.  Thus, I think that module names should be defined by strings and version numbers.  An import would then come of the form:
>
> import "Standard D Library: math" 1.3;
 ...
> To avoid parsing hundreds of files at once, I would suggest that libraries would include some sort of lookup database file.


Well, on this same note, I would argue a kinda similar yet notably different approach be taken.

The import concept as used in Java is incredibly well defined, non-ambiguous, and in practice, quite useful.

I apologize to those familiar with Java for the description I'm about to give, but it just helps me follow my description of the point I'm trying to make.  :)

In D, modules and source files have a 1 to 1 correspondance, just like public classes and source files in Java.  One java source file contains only one public class (or interface) and is compiled into the corresponding ".class" file.  The D spec points out the differences between modules and classes, of course, but the Java framework for importing classes could still be maintained for importing modules (perhaps with minor changes as needed?).

The main thing in java that keeps things seperated is the use of packages.
Classes can either belong to no package, in which case you import by class
name -
"import foo;"

or by package name then class name with dot notation.  ie -

foo.java -
"package language.d;
public class foo{}"

beginning of next source file -
"import language.d.foo;"

In java, you are forced to arrange the source files (and so it follow, the class files) into a directory hierarchy that matches the package naming scheme.  While it was troublesome at first, it's easy to get used to and beneficial for managing large projects later.  Also, it was made that way to solve the problem of people deciding to use the same class names as classes of the same name can coexist, as long as they belong to different packages

For example, all the library code I make, I put in the "master package" bradeeoh.  For example, I created my own ImageProducer class which is in the package "bradeeoh.image" and it doesn't conflict with the original one at all because it's in the package "java.awt.image"

This way of allowing same-named classes to coexist seems directly applicable to allowing same-named modules to coexist.

However, the "different versions of the same library" problem remains unsolved as they'd obviously have the same package and module names. However, you could, say, create a directly called "version1" and put the version 1.0 code hierarchy in that directory, and do the same in directory "version2".

In your D program, you could -

"import version1.language.d.foo;"
or
"import version2.language.d.foo;"

and the compiler/linker could automatically resolve which module you're importing.

Also, in Java, this allows you to refer to two classes of the same name as unique entities.  For example, recognizing that we're talking about modules instead of classes, in your code you could do this -

import language.d.foo;   // this module has a global integer variable named
x
import customlibrary.foo;  // so does this one

void someFunction( int q )
{
    language.d.foo.x = q++;
    customlibrary.foo.x = lanugage.d.foo.x + q;
}

Obviously, the syntax required in module source files and semantics of how the directory system works could be tweaked in a number of ways, but I love the way this works in Java and the admittedly biased opinion that follows thinks that it could work well in D as well.

Any other thoughts?

-Brady

My thought on this is just that the Java approach of essentially having nested namespaces is vastly superior to C++'s.  I think that D would do well to adopt it.

Peter.

"Bradeeoh" <bradeeoh@crosswinds.net> wrote in message news:9lnh4j$1gvk$1@digitaldaemon.com...
>
> "Russ Lewis" <russ@deming-os.org> wrote in message news:3B7F3E7E.C9766FC5@deming-os.org...
> > I was napping with my wife today, and as I woke, I had a wild thought. Importing modules only based on filenames is *extremely* restrictive. It prevents having multiple versions of a library installed on a machine, and it practically begs for trouble where people have different modules with the same file name.  Thus, I think that module names should be defined by strings and version numbers.  An import would then come of the form:
> >
> > import "Standard D Library: math" 1.3;
>  ...
> > To avoid parsing hundreds of files at once, I would suggest that libraries would include some sort of lookup database file.
>
>
> Well, on this same note, I would argue a kinda similar yet notably
different
> approach be taken.
>
> The import concept as used in Java is incredibly well defined, non-ambiguous, and in practice, quite useful.
>
> I apologize to those familiar with Java for the description I'm about to give, but it just helps me follow my description of the point I'm trying
to
> make.  :)
>
> In D, modules and source files have a 1 to 1 correspondance, just like public classes and source files in Java.  One java source file contains
only
> one public class (or interface) and is compiled into the corresponding ".class" file.  The D spec points out the differences between modules and classes, of course, but the Java framework for importing classes could
still
> be maintained for importing modules (perhaps with minor changes as
needed?).
>
> The main thing in java that keeps things seperated is the use of packages.
> Classes can either belong to no package, in which case you import by class
> name -
> "import foo;"
>
> or by package name then class name with dot notation.  ie -
>
> foo.java -
> "package language.d;
> public class foo{}"
>
> beginning of next source file -
> "import language.d.foo;"
>
> In java, you are forced to arrange the source files (and so it follow, the class files) into a directory hierarchy that matches the package naming scheme.  While it was troublesome at first, it's easy to get used to and beneficial for managing large projects later.  Also, it was made that way
to
> solve the problem of people deciding to use the same class names as
classes
> of the same name can coexist, as long as they belong to different packages
>
> For example, all the library code I make, I put in the "master package" bradeeoh.  For example, I created my own ImageProducer class which is in
the
> package "bradeeoh.image" and it doesn't conflict with the original one at all because it's in the package "java.awt.image"
>
> This way of allowing same-named classes to coexist seems directly
applicable
> to allowing same-named modules to coexist.
>
> However, the "different versions of the same library" problem remains unsolved as they'd obviously have the same package and module names. However, you could, say, create a directly called "version1" and put the version 1.0 code hierarchy in that directory, and do the same in directory "version2".
>
> In your D program, you could -
>
> "import version1.language.d.foo;"
> or
> "import version2.language.d.foo;"
>
> and the compiler/linker could automatically resolve which module you're importing.
>
> Also, in Java, this allows you to refer to two classes of the same name as unique entities.  For example, recognizing that we're talking about
modules
> instead of classes, in your code you could do this -
>
> import language.d.foo;   // this module has a global integer variable
named
> x
> import customlibrary.foo;  // so does this one
>
> void someFunction( int q )
> {
>     language.d.foo.x = q++;
>     customlibrary.foo.x = lanugage.d.foo.x + q;
> }
>
> Obviously, the syntax required in module source files and semantics of how the directory system works could be tweaked in a number of ways, but I
love
> the way this works in Java and the admittedly biased opinion that follows thinks that it could work well in D as well.
>
> Any other thoughts?
>
> -Brady
>
>

"kaffiene" <kaffiene@xtra.co.nz> wrote in message news:9lo1e2$1r4e$2@digitaldaemon.com...
> My thought on this is just that the Java approach of essentially having nested namespaces is vastly superior to C++'s.  I think that D would do
well
> to adopt it.
>
> Peter.


hahahah

you said in so few words what I said in so many.  thank you.  :)

-Brady

I agree that something like this will turn out to be necessary. I happen to not like java's way of spewing thousands of files all over a very deep directory structure. I sure get tired of cd ..\..\foo\ ...

"Bradeeoh" <bradeeoh@crosswinds.net> wrote in message news:9lotla$2aj2$1@digitaldaemon.com...
>
> "kaffiene" <kaffiene@xtra.co.nz> wrote in message news:9lo1e2$1r4e$2@digitaldaemon.com...
> > My thought on this is just that the Java approach of essentially having nested namespaces is vastly superior to C++'s.  I think that D would do
> well
> > to adopt it.
> >
> > Peter.
>
>
> hahahah
>
> you said in so few words what I said in so many.  thank you.  :)
>
> -Brady
>
>

Yeah, I didn't like it the first time I tried it (coming from a C, C++ backgound), but it's no bother in practice.  You end up setting your development environment with make files and editors which can cope with the subdirectories.  There's actually to need to cd into any of the subdirectories.

"Walter" <walter@digitalmars.com> wrote in message news:9m41g9$2v0b$1@digitaldaemon.com...
> I agree that something like this will turn out to be necessary. I happen
to
> not like java's way of spewing thousands of files all over a very deep directory structure. I sure get tired of cd ..\..\foo\ ...
>
> "Bradeeoh" <bradeeoh@crosswinds.net> wrote in message news:9lotla$2aj2$1@digitaldaemon.com...
> >
> > "kaffiene" <kaffiene@xtra.co.nz> wrote in message news:9lo1e2$1r4e$2@digitaldaemon.com...
> > > My thought on this is just that the Java approach of essentially
having
> > > nested namespaces is vastly superior to C++'s.  I think that D would
do
> > well
> > > to adopt it.
> > >
> > > Peter.
> >
> >
> > hahahah
> >
> > you said in so few words what I said in so many.  thank you.  :)
> >
> > -Brady
> >
> >
>
>

	On the admin side, I will say that I hat setting up start up scripts to
build classpathes though.  Having to grab the root of umpteen class
trees and a couple hundred jar/zip files gets old real fast.  I can
agree with the benefits, but the maintenance becomes hell after you get
a few java apps the require different runtimes, library
version/implementations.  It make one long of the days were the system
just knew where libraries lived.  CLASSPATH just feel like an
amplification of the problem that LIBPATH can cause.  Still, a
non-hierarchical namespace would ultimately hurt the language.

Dan

kaffiene wrote:
> 
> Yeah, I didn't like it the first time I tried it (coming from a C, C++ backgound), but it's no bother in practice.  You end up setting your development environment with make files and editors which can cope with the subdirectories.  There's actually to need to cd into any of the subdirectories.
> 
> "Walter" <walter@digitalmars.com> wrote in message news:9m41g9$2v0b$1@digitaldaemon.com...
> > I agree that something like this will turn out to be necessary. I happen
> to
> > not like java's way of spewing thousands of files all over a very deep directory structure. I sure get tired of cd ..\..\foo\ ...
> >
> > "Bradeeoh" <bradeeoh@crosswinds.net> wrote in message news:9lotla$2aj2$1@digitaldaemon.com...
> > >
> > > "kaffiene" <kaffiene@xtra.co.nz> wrote in message news:9lo1e2$1r4e$2@digitaldaemon.com...
> > > > My thought on this is just that the Java approach of essentially
> having
> > > > nested namespaces is vastly superior to C++'s.  I think that D would
> do
> > > well
> > > > to adopt it.
> > > >
> > > > Peter.
> > >
> > >
> > > hahahah
> > >
> > > you said in so few words what I said in so many.  thank you.  :)
> > >
> > > -Brady
> > >
> > >
> >
> >

Dan Hursh wrote:
> 	On the admin side, I will say that I hat setting up start up
 ...
> version/implementations.  It make one long of the days were the system
> just knew where libraries lived.  CLASSPATH just feel like an
> amplification of the problem that LIBPATH can cause.  Still, a
> non-hierarchical namespace would ultimately hurt the language.
> 
> Dan
> 
> ...
Are you sure?  I suspect that it would depend a lot on implementation details.  Eiffel does quite will with a non-hierarchical name-space. (It's problems come from an overly ridgid design of other features. [This is normally solved via linage to C routines, so it's no HUGE problem, but quite annoying.])

Charles Hixson wrote:
> 
> Dan Hursh wrote:
> >       On the admin side, I will say that I hat setting up start up
>   ...
> > version/implementations.  It make one long of the days were the system just knew where libraries lived.  CLASSPATH just feel like an amplification of the problem that LIBPATH can cause.  Still, a non-hierarchical namespace would ultimately hurt the language.
> >
> > Dan
> >
> > ...
> Are you sure?  I suspect that it would depend a lot on implementation details.  Eiffel does quite will with a non-hierarchical name-space. (It's problems come from an overly ridgid design of other features. [This is normally solved via linage to C routines, so it's no HUGE problem, but quite annoying.])

I could be wrong.  I haven't used eiffel myself, and I've never supported anyone using it.  It's alway been one of those text book languages.

Dan

Charles Hixson <charleshixsn@earthlink.net> writes:

> Are you sure?  I suspect that it would depend a lot on implementation
> details.  Eiffel does quite will with a non-hierarchical
> name-space.

Ada 95 added child units to Ada 83 (the Ada "namespace" has always been hierarchical in some sense).  When I look at my Ada code, I can hardly imagine what I would do without this feature.  Admittedly, Ada associates visibility with the package hierarchy, so there is a very natural way to use a package hierarchy to model a hierarchy of classes, but I still think this is a nice feature even if this strong connection isn't there.

(Namespaces in the C++ sense are of course a pain in the neck.  I hope no one considers them for any new language.)

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898