• Russ Lewis (21/21) Aug 18 2001 I was napping with my wife today, and as I woke, I had a wild thought.
• Bradeeoh (66/76) Aug 18 2001 ...
• kaffiene (18/95) Aug 19 2001 My thought on this is just that the Java approach of essentially having
• Bradeeoh (6/10) Aug 19 2001 well
• Walter (5/16) Aug 23 2001 I agree that something like this will turn out to be necessary. I happen...
• kaffiene (10/33) Aug 23 2001 Yeah, I didn't like it the first time I tried it (coming from a C, C++
• Dan Hursh (11/49) Aug 23 2001 On the admin side, I will say that I hat setting up start up scripts to
• Charles Hixson (7/16) Aug 24 2001 Are you sure? I suspect that it would depend a lot on implementation
• Dan Hursh (5/22) Aug 25 2001 I could be wrong. I haven't used eiffel myself, and I've never
• Florian Weimer (14/17) Aug 25 2001 Ada 95 added child units to Ada 83 (the Ada "namespace" has always
• Dan Hursh (5/7) Aug 25 2001 What's wrong with them? That's one feature I hadn't heard any problems
• Florian Weimer (10/15) Aug 27 2001 It is hard to design a reasonable separate compilation model around
• Dan Hursh (8/23) Aug 27 2001 Oh, I never tried to depend on them for compilation techniques. I
• Charles Hixson (19/39) Aug 27 2001 But Ada95 has packages that are sort of orthogonal to the tagged types.

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.

"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

"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

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

"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

well
 to adopt it.

 Peter.


hahahah

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

-Brady

"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

 well
 to adopt it.

 Peter.


 hahahah

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

 -Brady

"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

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 <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

 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

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
 
 ...

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.])

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

 ...

 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

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

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

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

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

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.)
 
 

But Ada95 has packages that are sort of orthogonal to the tagged types. 
  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.