The java import is very limited.
When you want to import a class you can't
specify directories.  There should be a way
to specify the class location instead of entering
it in the class path.

Example of a java import:

import java.awt.event.*;
import java.awt.Graphics;
import java.util.Stack;
import java.util.Vector;

I think this was a step backward.  You should
be able to specify a file location like you can
in C for some of the classes and libraries.
It would be better if D provided a method of specifying
the file path of a class.  D should follow a C style
convention of at least enabling a file path
for the classes.

An D example would be to import from directory /usr/bin
the class strings.utils.unicode:

import /usr/bin/strings.utils.unicode;

A java version is very painful if it is not part of Suns java library.  It is almost as if other libraries are an after thought with no way to specify where to import them.

import string.utils.unicode;

I think Java is very limited in the way that it imports classes and modules.  They tried to make the import object oriented but there is also a fine balance between having the ability to specify where it is.

As in Perl when you add a module you put it in a lib directory. So that this corresponds with a path.  Whereas if you want to use Xerces you have to go through a bunch of class path crap to define where it is located.

You have to add stuff to the class path such
as

/home/base/classes:.:/user/strings/utils.jar

<nsross@prodigy.net> wrote in message news:aebn06$1odu$1@digitaldaemon.com...
> The java import is very limited.
> When you want to import a class you can't
> specify directories.

This is intentional, and is a *good* thing.

The file system and directory layouts should be irrelevant to my source code.  In fact, my shop has a standard that says "thou shalt not use explicit paths in thy #include directives" and it has SERVED US WELL.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:aecgl4$2j2q$1@digitaldaemon.com...
> <nsross@prodigy.net> wrote in message news:aebn06$1odu$1@digitaldaemon.com...
> > The java import is very limited.
> > When you want to import a class you can't
> > specify directories.
>
> This is intentional, and is a *good* thing.
>
> The file system and directory layouts should be irrelevant to my source code.  In fact, my shop has a standard that says "thou shalt not use explicit paths in thy #include directives" and it has SERVED US WELL.
>
> --
> Richard Krehbiel, Arlington, VA, USA
> rich@kastle.com (work) or krehbiel3@comcast.net  (personal)
>



What about relative paths?

#include "engine/gravity.cpp"
#include "engine/ai.cpp"
#include "objects/monsters/orc.cpp"

Isn't it good to have some kind of hierarchy
in the source code? Relative to the directory
of the source file the imports / includes are
done in?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Hi,

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afci5h$1hn0$1@digitaldaemon.com...
> What about relative paths?
>
> #include "engine/gravity.cpp"
> #include "engine/ai.cpp"
> #include "objects/monsters/orc.cpp"
>
> Isn't it good to have some kind of hierarchy
> in the source code? Relative to the directory
> of the source file the imports / includes are
> done in?

No, it isn't. Not all platforms has the concept of directories. You will have problems porting this kind of code to eg. OS/390.

Regards,
Martin M. Pedersen

On Wed, 26 Jun 2002 16:26:27 +0200 "OddesE" <OddesE_XYZ@hotmail.com> wrote:

> What about relative paths?
> 
> #include "engine/gravity.cpp"
> #include "engine/ai.cpp"
> #include "objects/monsters/orc.cpp"
> 
> Isn't it good to have some kind of hierarchy
> in the source code? Relative to the directory
> of the source file the imports / includes are
> done in?

Hmm... I thought there are packages for this:

	import engine.gravity;
	import engine.ai;
	import objects.monsters.orc;

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afci5h$1hn0$1@digitaldaemon.com...
> "Richard Krehbiel" <rich@kastle.com> wrote in message news:aecgl4$2j2q$1@digitaldaemon.com...
> > <nsross@prodigy.net> wrote in message news:aebn06$1odu$1@digitaldaemon.com...
> > > The java import is very limited.
> > > When you want to import a class you can't
> > > specify directories.
> >
> > This is intentional, and is a *good* thing.
> >
> > The file system and directory layouts should be irrelevant to my source code.  In fact, my shop has a standard that says "thou shalt not use explicit paths in thy #include directives" and it has SERVED US WELL.
>
> What about relative paths?
>
> #include "engine/gravity.cpp"
> #include "engine/ai.cpp"
> #include "objects/monsters/orc.cpp"
>
> Isn't it good to have some kind of hierarchy
> in the source code? Relative to the directory
> of the source file the imports / includes are
> done in?

It may well be valuable to have logical heirarchies of include files, but that doesn't mean the heirarchy should be exposed in the source code.  Use of the -I include path compiler switch and the INCLUDE= environment variable allow any such heirarchies without coding the heirarchy in the source.

Practially speaking, I have experienced changes to include path heirarchies. I only had to change my makefiles.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

Agreed

"Richard Krehbiel" <rich@kastle.com> wrote in message news:afcv2l$225e$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afci5h$1hn0$1@digitaldaemon.com...
> > "Richard Krehbiel" <rich@kastle.com> wrote in message news:aecgl4$2j2q$1@digitaldaemon.com...
> > > <nsross@prodigy.net> wrote in message news:aebn06$1odu$1@digitaldaemon.com...
> > > > The java import is very limited.
> > > > When you want to import a class you can't
> > > > specify directories.
> > >
> > > This is intentional, and is a *good* thing.
> > >
> > > The file system and directory layouts should be irrelevant to my
source
> > > code.  In fact, my shop has a standard that says "thou shalt not use explicit paths in thy #include directives" and it has SERVED US WELL.
> >
> > What about relative paths?
> >
> > #include "engine/gravity.cpp"
> > #include "engine/ai.cpp"
> > #include "objects/monsters/orc.cpp"
> >
> > Isn't it good to have some kind of hierarchy
> > in the source code? Relative to the directory
> > of the source file the imports / includes are
> > done in?
>
> It may well be valuable to have logical heirarchies of include files, but that doesn't mean the heirarchy should be exposed in the source code.  Use of the -I include path compiler switch and the INCLUDE= environment
variable
> allow any such heirarchies without coding the heirarchy in the source.
>
> Practially speaking, I have experienced changes to include path
heirarchies.
> I only had to change my makefiles.
>
> --
> Richard Krehbiel, Arlington, VA, USA
> rich@kastle.com (work) or krehbiel3@comcast.net  (personal)
>
>
>

You know what?   SCREW OS/390.

Sean

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:afckpn$1las$1@digitaldaemon.com...
> Hi,
>
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afci5h$1hn0$1@digitaldaemon.com...
> > What about relative paths?
> >
> > #include "engine/gravity.cpp"
> > #include "engine/ai.cpp"
> > #include "objects/monsters/orc.cpp"
> >
> > Isn't it good to have some kind of hierarchy
> > in the source code? Relative to the directory
> > of the source file the imports / includes are
> > done in?
>
> No, it isn't. Not all platforms has the concept of directories. You will have problems porting this kind of code to eg. OS/390.
>
> Regards,
> Martin M. Pedersen

Global search and replace is commonly available.

Seriously this kind of change is rare and isn't that hard to accomplish.

I'd rather support easier compilation for *small* apps (D will have to be a grassroots effort at first).  I really don't mind the path being in the source files, in fact I think it belongs there.

Relative paths would also reduce problems with more than one library having a module with the same name.

Imagine:

import engine\math;
import phobos\math;
import common\math;
import utility\extras\mystuff\math;

Sean

"Richard Krehbiel" <rich@kastle.com> wrote in message news:afcv2l$225e$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afci5h$1hn0$1@digitaldaemon.com...
> > "Richard Krehbiel" <rich@kastle.com> wrote in message news:aecgl4$2j2q$1@digitaldaemon.com...
> > > <nsross@prodigy.net> wrote in message news:aebn06$1odu$1@digitaldaemon.com...
> > > > The java import is very limited.
> > > > When you want to import a class you can't
> > > > specify directories.
> > >
> > > This is intentional, and is a *good* thing.
> > >
> > > The file system and directory layouts should be irrelevant to my
source
> > > code.  In fact, my shop has a standard that says "thou shalt not use explicit paths in thy #include directives" and it has SERVED US WELL.
> >
> > What about relative paths?
> >
> > #include "engine/gravity.cpp"
> > #include "engine/ai.cpp"
> > #include "objects/monsters/orc.cpp"
> >
> > Isn't it good to have some kind of hierarchy
> > in the source code? Relative to the directory
> > of the source file the imports / includes are
> > done in?
>
> It may well be valuable to have logical heirarchies of include files, but that doesn't mean the heirarchy should be exposed in the source code.  Use of the -I include path compiler switch and the INCLUDE= environment
variable
> allow any such heirarchies without coding the heirarchy in the source.
>
> Practially speaking, I have experienced changes to include path
heirarchies.
> I only had to change my makefiles.
>
> --
> Richard Krehbiel, Arlington, VA, USA
> rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

Sean L. Palmer wrote:

> Global search and replace is commonly available.
> 
> Seriously this kind of change is rare and isn't that hard to accomplish.
> 
> I'd rather support easier compilation for *small* apps (D will have to be
> a
> grassroots effort at first).  I really don't mind the path being in the
> source files, in fact I think it belongs there.
> 
> Relative paths would also reduce problems with more than one library having a module with the same name.
> 
> Imagine:
> 
> import engine\math;
> import phobos\math;
> import common\math;
> import utility\extras\mystuff\math;
> 
> Sean

Agreed, but please please please do not use back slashes (use forward slashes instead, or colons).  The backslash key on each of my 6 keyboard is in a different place - and on one it is completely absent.

C 2002/6/27