www.digitalmars.com         C & C++   DMDScript  

D - More Useful (but Complex) Imports

reply Russ Lewis <russ deming-os.org> writes:
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.
Aug 18 2001
parent reply "Bradeeoh" <bradeeoh crosswinds.net> writes:
"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
Aug 18 2001
parent reply "kaffiene" <kaffiene xtra.co.nz> writes:
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

 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

 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

 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

 be maintained for importing modules (perhaps with minor changes as

 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

 solve the problem of people deciding to use the same class names as

 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

 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

 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

 instead of classes, in your code you could do this -

 import language.d.foo;   // this module has a global integer variable

 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

 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

Aug 19 2001
parent reply "Bradeeoh" <bradeeoh crosswinds.net> writes:
"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

 to adopt it.

 Peter.

hahahah you said in so few words what I said in so many. thank you. :) -Brady
Aug 19 2001
parent reply "Walter" <walter digitalmars.com> writes:
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

 to adopt it.

 Peter.

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

Aug 23 2001
parent reply "kaffiene" <kaffiene xtra.co.nz> writes:
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

 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



 nested namespaces is vastly superior to C++'s.  I think that D would



 well
 to adopt it.

 Peter.

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


Aug 23 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
	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

 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



 nested namespaces is vastly superior to C++'s.  I think that D would



 well
 to adopt it.

 Peter.

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



Aug 23 2001
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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
 
 ...

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.])
Aug 24 2001
next sibling parent Dan Hursh <hursh infonet.isl.net> writes:
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

 ...

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
Aug 25 2001
prev sibling parent reply Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
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
Aug 25 2001
next sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
 
 (Namespaces in the C++ sense are of course a pain in the neck.  I hope
 no one considers them for any new language.)

What's wrong with them? That's one feature I hadn't heard any problems about before. They were an improvement over what I've had in the other languages I've used. Dan
Aug 25 2001
parent reply Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
Dan Hursh <hursh infonet.isl.net> writes:

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

What's wrong with them?

It is hard to design a reasonable separate compilation model around them because each compilation unit can open any namespace and define things in it. In addition, namespaces do not address at all the problem of the correct order of initialization of subsystems. -- 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
Aug 27 2001
parent Dan Hursh <hursh infonet.isl.net> writes:
Florian Weimer wrote:
 
 Dan Hursh <hursh infonet.isl.net> writes:
 
 (Namespaces in the C++ sense are of course a pain in the neck.  I hope
 no one considers them for any new language.)

What's wrong with them?

It is hard to design a reasonable separate compilation model around them because each compilation unit can open any namespace and define things in it. In addition, namespaces do not address at all the problem of the correct order of initialization of subsystems.

Oh, I never tried to depend on them for compilation techniques. I actually like it so I can define related objects in related or nested namespaces together. It comes in handy for small platform dependent interfaces. Namespaces are not modules though on their own. Well not without discipline. I'm good at discipline when I need to be. I just like not having it forced on me. Dan
Aug 27 2001
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Florian Weimer wrote:
 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.)

So you do have a partial lattice structure of -- if not of inheritance, of dependancy. And I don't think inheritance is too strong a term. It's not quite what a normal OO language would call inheritance, but then neither is Ada a normal OO language. So the code isn't actually hierarchical. It's more of a lattice structure, though their is a main line of inheritance that the child packages and tagged types follow. To me this feels a bit like the families that trace their descent through the paternal line, and ignore who the mothers were. Silly. One half is just as important as the other. (Frequently more so, when the official line of inheritance is disemboweled, and replaced by code from a totally different line.) Multiple inheritance is more like the code actually operates. An inheritance tree is how the user interface operates. So ideally there would be a way to specify both. Unfortunately, the way this usually gets done is with a bunch of one line forwarding functions. It's flexible, but I can't think of anything else to reccommend it.
Aug 27 2001