www.digitalmars.com         C & C++   DMDScript  

D - D should provide file paths for import

reply nsross prodigy.net writes:
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
Jun 13 2002
parent reply "Richard Krehbiel" <rich kastle.com> writes:
<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)
Jun 14 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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
Jun 26 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
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
Jun 26 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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

Jun 27 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

You might not care about portability, but it is a primary concern to me. At work, we develop software to whatever platforms the customers are using, and we don't expect the customers to change platform to whatever is supported by our tools. Instead we have to select our tools, such as compilers and languages, to fit the customers needs. OS/390 is big in big businesses such as the financial sector, and to address such markeds, you have to support it. C/C++ supports wierd platforms like this very fine, and so should any viable successor. Regards, Martin M. Pedersen
Jun 27 2002
next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:aff9o4$1n7m$1 digitaldaemon.com...
 Hi,

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

You might not care about portability, but it is a primary concern to me.

 work, we develop software to whatever platforms the customers are using,

 we don't expect the customers to change platform to whatever is supported

 our tools. Instead we have to select our tools, such as compilers and
 languages, to fit the customers needs. OS/390 is big in big businesses

 as the financial sector, and to address such markeds, you have to support
 it. C/C++ supports wierd platforms like this very fine, and so should any
 viable successor.

 Regards,
 Martin M. Pedersen

Still, C/C++ also allow pathnames in includes, so what's your point? If you need portability, just don't use pathnames in imports. Me personally I couldn't care less about OS/390... -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jun 27 2002
prev sibling next sibling parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:aff9o4$1n7m$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

You might not care about portability, but it is a primary concern to me.

 work, we develop software to whatever platforms the customers are using,

 we don't expect the customers to change platform to whatever is supported

 our tools. Instead we have to select our tools, such as compilers and
 languages, to fit the customers needs. OS/390 is big in big businesses

 as the financial sector, and to address such markeds, you have to support
 it. C/C++ supports wierd platforms like this very fine, and so should any
 viable successor.

Can't you cross-compile from a development system that's nicer than that? Do you really need to compile in the OS/360 itself? Salutaciones, JCAB
Jun 27 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Any OS that doesn't support directories is going to have serious problematic
issues as a development platform.  It's ok for the target platform not to
support directories.  Some embedded systems may not even have an OS or
filesystem at all..  But the development platform *MUST* support
directories.  This is 2002 dammit.

Sean

"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:aff9o4$1n7m$1 digitaldaemon.com...
 Hi,

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

You might not care about portability, but it is a primary concern to me.

 work, we develop software to whatever platforms the customers are using,

 we don't expect the customers to change platform to whatever is supported

 our tools. Instead we have to select our tools, such as compilers and
 languages, to fit the customers needs. OS/390 is big in big businesses

 as the financial sector, and to address such markeds, you have to support
 it. C/C++ supports wierd platforms like this very fine, and so should any
 viable successor.

 Regards,
 Martin M. Pedersen

Jun 27 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
But we have packages in D, which are simular but more portable. In Unix the
slash goes one way while in windows the slash goes the other. Java also uses
packages for cross-portability. Why do we need directory hierarchies as
well?

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:afgon3$h3b$1 digitaldaemon.com...
 Any OS that doesn't support directories is going to have serious

 issues as a development platform.  It's ok for the target platform not to
 support directories.  Some embedded systems may not even have an OS or
 filesystem at all..  But the development platform *MUST* support
 directories.  This is 2002 dammit.

 Sean

 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:aff9o4$1n7m$1 digitaldaemon.com...
 Hi,

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

You might not care about portability, but it is a primary concern to me.

 work, we develop software to whatever platforms the customers are using,

 we don't expect the customers to change platform to whatever is


 by
 our tools. Instead we have to select our tools, such as compilers and
 languages, to fit the customers needs. OS/390 is big in big businesses

 as the financial sector, and to address such markeds, you have to


 it. C/C++ supports wierd platforms like this very fine, and so should


 viable successor.

 Regards,
 Martin M. Pedersen


Jun 27 2002
prev sibling parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:afgon3$h3b$1 digitaldaemon.com...
 Any OS that doesn't support directories is going to have serious

 issues as a development platform.

Other OS'es have other concepts, and might support development very well. This is eg. the case with OS/390. I'm haven't worked on such big iron myself, but I have part of a development group writing software being compiled on it.
 But the development platform *MUST* support directories.  This is 2002

You can expect any platform to support modules and packages, but it might be implemented differently. You cannot, however, expect to always being able to address directories using a Microsoft or UNIX syntax. Regards, Martin M. Pedersen
Jun 28 2002
prev sibling next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

 Sean

I tend to agree. If an OS you want to target doesn't support directories, then simply don't use them in your source. Portability is good, but it shouldn't be enforced. If I want to write platform dependant code, then please let me. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jun 27 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:afek1t$pev$1 digitaldaemon.com...
 You know what?   SCREW OS/390.

 Sean

LOL. Some things are rightfully left in the dustbin of history, worthy of maintaining existing support but not worthy of crippling new designs. These include: 1) 16 bit architectures 2) CPUs with no hardware stack 3) non-IEEE floating point (i.e. VAX floating point) 4) non-2's complement arithmetic 5) EBCDIC etc.
Jul 02 2002
parent reply andy <acoliver apache.org> writes:
Walter wrote:
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:afek1t$pev$1 digitaldaemon.com...
 
You know what?   SCREW OS/390.


hehe
Sean

LOL. Some things are rightfully left in the dustbin of history, worthy of maintaining existing support but not worthy of crippling new designs. These include: 1) 16 bit architectures

+1
 2) CPUs with no hardware stack

+1
 3) non-IEEE floating point (i.e. VAX floating point)

+1
 4) non-2's complement arithmetic

not sure about that one...What will you do when a (moderately mass produced) processor based on positive, negative, neutral charge (or + & minus) or something of the such comes a long and does something like this: 0000 = 0 0001 = 1 0002 = 2 0010 = 3 This seems like it may end up being an evolutionary rather than revolutionary step in processor technology.
 5) EBCDIC
 

+1 - You do realize you're risking mass hordes of true IBMers coming after you in mobs...
 etc.
 
 

On that note. I'm curious why the "extended" datatype. I find it a bit queer in reference to the other datatypes. I understand its purpose, but it seems directly counter to the other datatypes. I think I'd rather see "extended80" and "extended96" or something of the such with an eye towards processor optimization. Meaning while extended80 would be a native processor implemnetation on an intel chip, it might not be on another, but would be defined solidly. The "extended96" would of course would be implemented by the software and not the hardware on an intel chip. (and its just a guess as to what an extended type might be on some other platform). I have the same concern with wchar. It seems to me more logical to provide a defined datatype, and let those who know that its 16 bit on windows and who want to optimize for windows, use the wchar16. If you don't know, or you don't care, etc, then you'll just choose what's appropriate and perhaps miss the fact that you could have done it more efficiently otherwise. Does that make sense? -Andy
Jul 02 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
andy wrote:

 4) non-2's complement arithmetic

not sure about that one...What will you do when a (moderately mass produced) processor based on positive, negative, neutral charge (or + & minus) or something of the such comes a long and does something like this: 0000 = 0 0001 = 1 0002 = 2 0010 = 3 This seems like it may end up being an evolutionary rather than revolutionary step in processor technology.

From what I've read, the trinary computing guys model the digits as -1,0,1: 0000 = 0 0001 = 1 001-1 = 2 0010 = 3 0011 = 4 01-1-1 = 5 D should support trinary computing when it comes out...no need to do it now :) -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jul 02 2002
next sibling parent Karl Bochert <kbochert ix.netcom.com> writes:
On Tue, 02 Jul 2002 11:51:08 -0700, Russ Lewis
<spamhole-2001-07-16 deming-os.org> wrote:
 andy wrote:
 
 
 From what I've read, the trinary computing guys model the digits as -1,0,1:
 
 0000 = 0
 0001 = 1
 001-1 = 2
 0010 = 3
 0011 = 4
 01-1-1 = 5
 
 D should support trinary computing when it comes out...no need to do it now :)
 

The latest thing is quantum computing with each bit being 0, 1 or both, but I guess thats still just binary (with three states!).
Jul 03 2002
prev sibling parent andy <acoliver apache.org> writes:
Right the point was that "non-2's complement arithmetic" may have a 
place in the future.

-Andy

Russ Lewis wrote:
 andy wrote:
 
 
4) non-2's complement arithmetic

not sure about that one...What will you do when a (moderately mass produced) processor based on positive, negative, neutral charge (or + & minus) or something of the such comes a long and does something like this: 0000 = 0 0001 = 1 0002 = 2 0010 = 3 This seems like it may end up being an evolutionary rather than revolutionary step in processor technology.

From what I've read, the trinary computing guys model the digits as -1,0,1: 0000 = 0 0001 = 1 001-1 = 2 0010 = 3 0011 = 4 01-1-1 = 5 D should support trinary computing when it comes out...no need to do it now :) -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]

Jul 03 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"andy" <acoliver apache.org> wrote in message
news:3D21E34E.3050907 apache.org...
 On that note.  I'm curious why the "extended" datatype.  I find it a bit
 queer in reference to the other datatypes.  I understand its purpose,
 but it seems directly counter to the other datatypes.  I think I'd
 rather see "extended80" and "extended96" or something of the such with
 an eye towards processor optimization.  Meaning while extended80 would
 be a native processor implemnetation on an intel chip, it might not be
 on another, but would be defined solidly.  The "extended96" would of
 course would be implemented by the software and not the hardware on an
 intel chip.  (and its just a guess as to what an extended type might be
 on some other platform).

 I have the same concern with wchar.  It seems to me more logical to
 provide a defined datatype, and let those who know that its 16 bit on
 windows and who want to optimize for windows, use the wchar16.  If you
 don't know, or you don't care, etc, then you'll just choose what's
 appropriate and perhaps miss the fact that you could have done it more
 efficiently otherwise.

 Does that make sense?

"extended" is supported by the hardware, it just makes sense to have it accessible from the language.
Jul 02 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Wed=2C 26 Jun 2002 16=3A26=3A27 +0200 =22OddesE=22
=3COddesE=5FXYZ=40hotmail=2Ecom=3E wrote=3A

=3E What about relative paths=3F
=3E 
=3E #include =22engine=2Fgravity=2Ecpp=22
=3E #include =22engine=2Fai=2Ecpp=22
=3E #include =22objects=2Fmonsters=2Forc=2Ecpp=22
=3E 
=3E Isn't it good to have some kind of hierarchy
=3E in the source code=3F Relative to the directory
=3E of the source file the imports =2F includes are
=3E done in=3F

Hmm=2E=2E=2E I thought there are packages for this=3A

=09import engine=2Egravity=3B
=09import engine=2Eai=3B
=09import objects=2Emonsters=2Eorc=3B
Jun 26 2002
parent "Walter" <walter digitalmars.com> writes:
Yes, you're right.


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374338619483102 news.digitalmars.com...
Hmm... I thought there are packages for this:
import engine.gravity;
import engine.ai;
import objects.monsters.orc;
Jul 02 2002
prev sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"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)
Jun 26 2002
next sibling parent "Matthew Wilson" <matthew thedjournal.com> writes:
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



 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

 allow any such heirarchies without coding the heirarchy in the source.

 Practially speaking, I have experienced changes to include path

 I only had to change my makefiles.

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

Jun 26 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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



 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

 allow any such heirarchies without coding the heirarchy in the source.

 Practially speaking, I have experienced changes to include path

 I only had to change my makefiles.

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

Jun 27 2002
next sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
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
Jun 27 2002
next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I'm ok with forward slashes, they're the "de facto" standard path separator
for every OS except windoze.

Sean

"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:afeolg$tnn$1 digitaldaemon.com...
 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


 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

 in a different place - and on one it is completely absent.

 C 2002/6/27

Jun 27 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:afgok0$h31$1 digitaldaemon.com...
 I'm ok with forward slashes, they're the "de facto" standard path

 for every OS except windoze.

 Sean

Unfortunately Windows is the de facto standard operating system for every consumer computer. And that's a lot! Personally I do not see why all OS'es, Windows as well as all the others don't just make both characters valid? However, C/C++ allow forward slashes in their includes and it works perfectly, also on Windows. So this shouldn't be a problem. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jun 28 2002
next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:afhnhj$1qkr$1 digitaldaemon.com...

 Personally I do not see why all OS'es, Windows as well
 as all the others don't just make both characters valid?

Well, the backslash is a special character in C++. Try something like this in a standard-compliant compiler: #include <something\uaefe.h> and it will not do what you think it should, even if it supports using the backslash for paths. In case you don't know what I'm talking about: \uXXXX is supposed to be translated in the first phase into the UNICODE character represented by the XXXX number in hex. The bottomline is that it would be best if paths were normalized to using forward-slashes only. But that's bad for Windows. I don't think there's a perfect solution to this. What we have is probably the best possible, considering. Salutaciones, JCAB
Jun 28 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri, 28 Jun 2002 10:34:13 -0700 "Juan Carlos Arevalo Baeza" 
<jcab roningames.com> wrote:

    The bottomline is that it would be best if paths were normalized to using
 forward-slashes only. But that's bad for Windows. I don't think there's a

Why is it bad for Windows? It works, after all...a
Jun 29 2002
next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374364869616319 news.digitalmars.com...
 On Fri, 28 Jun 2002 10:34:13 -0700 "Juan Carlos Arevalo Baeza"
 <jcab roningames.com> wrote:

    The bottomline is that it would be best if paths were normalized to


 forward-slashes only. But that's bad for Windows. I don't think there's


 Why is it bad for Windows? It works, after all...a

It's mostly a mindset thing, since both work fine with the file system APIs; however, forward slashes really don't work with most Windows command-line tools, so if you get used to using them as path separators, and then you need to spawn a tool or script with a file name, you might be in for a surprise. Why can't forward slashes work on the command line too? Um - it's a long story. In the primordial DEC operating systems (RT-11) that CP-M were modelled after, a colon ":" indicates a device name, the forward slash distinguishes a command line options from file names, and there are no such things as heirarchical directories. The original MS-DOS (ca 1980) copied command line conventions for slash and colon from CP-M, and like CP-M, had no directories. Later versions of MS-DOS started copying Unix capabilities like heirarchical directories and pipelines. But, Unix uses the forward slash for path separator. MS-DOS adopted the backslash for a path separator, so that the forward slash could remain as the option introducer. Internally, however, in the API where there's no ambiguity, MS-DOS also honored forward slashes as path separators, to try to make life a bit easier for programmers porting their Unix apps. And so it has continued to this day. -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Jul 01 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Mon, 1 Jul 2002 09:05:34 -0400 "Richard Krehbiel" <rich kastle.com> wrote:

 It's mostly a mindset thing, since both work fine with the file system APIs;
 however, forward slashes really don't work with most Windows command-line
 tools, so if you get used to using them as path separators, and then you
 need to spawn a tool or script with a file name, you might be in for a
 surprise.

I am aware of that. However, we were discussing the import statement (and its C++ #include analogue), which relies on API, and supports back slashes quite happily. In fact, using \ in pathnames in #include is considered bad practice even om Windows (or so I heard). At least / works everywhere. As for system() and alike, well, it has platform-dependent behaviour by design, I guess.
Jul 01 2002
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374387634624421 news.digitalmars.com...
 On Mon, 1 Jul 2002 09:05:34 -0400 "Richard Krehbiel" <rich kastle.com>

 It's mostly a mindset thing, since both work fine with the file system


 however, forward slashes really don't work with most Windows


 tools, so if you get used to using them as path separators, and then you
 need to spawn a tool or script with a file name, you might be in for a
 surprise.

I am aware of that. However, we were discussing the import statement (and its C++ #include analogue), which relies on API, and supports back slashes quite happily. In fact, using \ in pathnames in #include is considered bad practice even om Windows (or so I heard). At least / works everywhere. As for system() and alike, well, it has platform-dependent behaviour by design, I guess.

Yeah, well, I'm still voting not to introduce the notion of file system path in import directives. I want to be able to take a project whose components exists in seventeen different places, .ZIP it, carry it somewhere, expand it to a single directory, and build it. I have done things like this, for on-site customer support (carry with me a dev environment and a project's sources on a CD). If the language allows specific paths in import directives, then I'll be able to carry *my* projects around like this (because I'm careful to avoid explicit paths), but not *yours* (which my manager will dump into my lap when you quit). I've already got languages which subject me to this; why should I adopt D if it's no better? -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Jul 01 2002
next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Because it makes *my* life easier to be able to avoid using a makefile
entirely.  And to do that I have to tell the compiler where to find my
modules.  That can be done either in the IDE or in the source files.

Maybe they could give you a command line option such as

dmd -remap("oldpath.oldmodule", "newpath.newsubdir.newmodule")

for moving other people's modules around without global search and replace.
Not that you couldn't easily find a global search and replace tool that
could replace all

    import oldpath.oldmodule;

with

    import newpath.newsubdir.newmodule;

If you like makefiles, you'll love command line tools.  I personally despise
both as historical artifacts.  I want modern tools that automate this crap
or at least put a pretty interface on it.

Sean

"Richard Krehbiel" <rich kastle.com> wrote in message
news:afpp21$2hr4$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374387634624421 news.digitalmars.com...
 On Mon, 1 Jul 2002 09:05:34 -0400 "Richard Krehbiel" <rich kastle.com>

 It's mostly a mindset thing, since both work fine with the file system


 however, forward slashes really don't work with most Windows


 tools, so if you get used to using them as path separators, and then



 need to spawn a tool or script with a file name, you might be in for a
 surprise.

I am aware of that. However, we were discussing the import statement (and its C++ #include analogue), which relies on API, and supports back slashes quite happily. In fact, using \ in pathnames in #include is considered bad practice even om Windows (or so I heard). At least / works everywhere. As for system() and alike, well, it has platform-dependent behaviour by design, I guess.

Yeah, well, I'm still voting not to introduce the notion of file system

 in import directives.  I want to be able to take a project whose

 exists in seventeen different places, .ZIP it, carry it somewhere, expand

 to a single directory, and build it.  I have done things like this, for
 on-site customer support (carry with me a dev environment and a project's
 sources on a CD).

 If the language allows specific paths in import directives, then I'll be
 able to carry *my* projects around like this (because I'm careful to avoid
 explicit paths), but not *yours* (which my manager will dump into my lap
 when you quit).  I've already got languages which subject me to this; why
 should I adopt D if it's no better?

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

Jul 01 2002
prev sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Mon, 1 Jul 2002 10:37:25 -0400 "Richard Krehbiel" <rich kastle.com> wrote:

 Yeah, well, I'm still voting not to introduce the notion of file system path
 in import directives.  I want to be able to take a project whose components
 exists in seventeen different places, .ZIP it, carry it somewhere, expand it
 to a single directory, and build it.  I have done things like this, for
 on-site customer support (carry with me a dev environment and a project's
 sources on a CD).

Since most D implementations are going to implement packages using directories (it just seems to be most logical solution), I guess it won't be possible that easy. Only maybe if Walter allows us to alias modules? Or some alternative way to define packages (like, say, a .dpk file which is just a list of modules). But then again, I also think that it's better to think in terms of modules and packages rather than files and directories. It's more abstract. While I wouldn't mind using / to separate package names in import directive (even though it _might_ be completely unrelated to directories in some implementations), but dot also okay.
Jul 01 2002
next sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Pavel Minayev wrote:

 Since most D implementations are going to implement packages using
 directories (it just seems to be most logical solution), I guess
 it won't be possible that easy. Only maybe if Walter allows us to
 alias modules? Or some alternative way to define packages (like, say,
 a .dpk file which is just a list of modules).

This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem. For example (in myProject.dpk). version Windows { module phobos = "c:\dmd\import\phobos"; /* etcetra */ } version Unix { module phobos = "//usr/import/phobos"; /* etcetra */ } If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary. All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
 But then again, I also think that it's better to think in terms
 of modules and packages rather than files and directories. It's
 more abstract. While I wouldn't mind using / to separate package
 names in import directive (even though it _might_ be completely
 unrelated to directories in some implementations), but dot also okay.

Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out, platform independent and consistant with the remainder of the D language. C 2002/7/2
Jul 02 2002
next sibling parent Kublai Kahn <Kublai_member pathlink.com> writes:
In article <afs4qp$1rsn$1 digitaldaemon.com>, C.R.Chafer says...
Pavel Minayev wrote:

 Since most D implementations are going to implement packages using
 directories (it just seems to be most logical solution), I guess
 it won't be possible that easy. Only maybe if Walter allows us to
 alias modules? Or some alternative way to define packages (like, say,
 a .dpk file which is just a list of modules).

This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem. For example (in myProject.dpk). version Windows { module phobos = "c:\dmd\import\phobos"; /* etcetra */ } version Unix { module phobos = "//usr/import/phobos"; /* etcetra */ } If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary. All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
 But then again, I also think that it's better to think in terms
 of modules and packages rather than files and directories. It's
 more abstract. While I wouldn't mind using / to separate package
 names in import directive (even though it _might_ be completely
 unrelated to directories in some implementations), but dot also okay.

Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out, platform independent and consistant with the remainder of the D language. C 2002/7/2

Feb 01 2003
prev sibling parent reply Kublai Kahn <Kublai_member pathlink.com> writes:
In article <afs4qp$1rsn$1 digitaldaemon.com>, C.R.Chafer says...
Pavel Minayev wrote:

 Since most D implementations are going to implement packages using
 directories (it just seems to be most logical solution), I guess
 it won't be possible that easy. Only maybe if Walter allows us to
 alias modules? Or some alternative way to define packages (like, say,
 a .dpk file which is just a list of modules).

This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem. For example (in myProject.dpk). version Windows { module phobos = "c:\dmd\import\phobos"; /* etcetra */ } version Unix { module phobos = "//usr/import/phobos"; /* etcetra */ } If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary. All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
 But then again, I also think that it's better to think in terms
 of modules and packages rather than files and directories. It's
 more abstract. While I wouldn't mind using / to separate package
 names in import directive (even though it _might_ be completely
 unrelated to directories in some implementations), but dot also okay.

Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out, platform independent and consistant with the remainder of the D language. C 2002/7/2

Here is another way for including file path imports in D. Perl 5 allows you to specify a library path for modules. The syntax in Perl 5 is: use lib "/pojects/group/path/lib"; You can even use a Windows path in Active Perl for Win32. Windows may use a Unix style path when Microsoft overhauls the windows shell in future releases. With this language facility you can search for classes or libraries in a directory path as well as the local path and program path. The following is a Unix example: import stdio; using library "/home/standard/ext/"; import graphics; This would be a Windows example: import stdio; using library "C:/homes/standard/ext/"; import graphics; You import stdio, but the class or files can also be located within a directory /home/standard/ext/ that is outside of the classpath. It will search for the graphics file in this directory if it isn't in the local or standard path. You can maintain import conventions but have the ability to define a external classpath.
Feb 01 2003
parent reply Kublai Kahn <Kublai_member pathlink.com> writes:
In article <b1hs0k$5hn$1 digitaldaemon.com>, Kublai Kahn says...
In article <afs4qp$1rsn$1 digitaldaemon.com>, C.R.Chafer says...
Pavel Minayev wrote:

 Since most D implementations are going to implement packages using
 directories (it just seems to be most logical solution), I guess
 it won't be possible that easy. Only maybe if Walter allows us to
 alias modules? Or some alternative way to define packages (like, say,
 a .dpk file which is just a list of modules).

This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem. For example (in myProject.dpk). version Windows { module phobos = "c:\dmd\import\phobos"; /* etcetra */ } version Unix { module phobos = "//usr/import/phobos"; /* etcetra */ } If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary. All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
 But then again, I also think that it's better to think in terms
 of modules and packages rather than files and directories. It's
 more abstract. While I wouldn't mind using / to separate package
 names in import directive (even though it _might_ be completely
 unrelated to directories in some implementations), but dot also okay.

Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out, platform independent and consistant with the remainder of the D language. C 2002/7/2

Here is another way for including file path imports in D. Perl 5 allows you to specify a library path for modules. The syntax in Perl 5 is: use lib "/pojects/group/path/lib"; You can even use a Windows path in Active Perl for Win32. Windows may use a Unix style path when Microsoft overhauls the windows shell in future releases. With this language facility you can search for classes or libraries in a directory path as well as the local path and program path. The following is a Unix example: import stdio; using library "/home/standard/ext/"; import graphics; This would be a Windows example: import stdio; using library "C:/homes/standard/ext/"; import graphics; You import stdio, but the class or files can also be located within a directory /home/standard/ext/ that is outside of the classpath. It will search for the graphics file in this directory if it isn't in the local or standard path. You can maintain import conventions but have the ability to define a external classpath.

In Java it restricts you to one import per line. Such as: import Java.awt.Graphics; import Java.applet.Applet; It won't let you import multiple includes on one line. import Java.awt.Graphics, Java.applet.Applet; Could D allow you to import more than one library per line? Is this a good idea? Please comment...
Feb 10 2003
parent C <blackmarlin asean-mail.com> writes:
Kublai Kahn wrote:

 In Java it restricts you to one import per line.
 Such as:
 
 import Java.awt.Graphics;
 import Java.applet.Applet;
 
 It won't let you import multiple includes on one line.
 import Java.awt.Graphics, Java.applet.Applet;
 
 Could D allow you to import more than one library per line?
 Is this a good idea? Please comment...

I expect D could very easily add such an extension (with probably no more than a dozen lines of extra code), however this is no more than simple syntax sugar to save typing a few characters (in this case 5). My other misgiving about this idea is that the comma and full stop characters are difficult to differentiate in many proportional fonts (not every one programmes using text mode, many people use an IDE which may make spotting the difference between the lines import d.mod,other; import d.mod.other; very difficult, which could lead to the intent of programmes being missinterpreted (syntax errors may also be a problem, changing the semantics of the line if a comma is used in place of a full stop, however I expect the compiler should be able to detect such typographical errors - in some cases checking for this error may prove difficult, or may result in wierd errors at the link stage). In summary, I see little benifit for adding such a convention and several pitfalls, my recommendation would be for D to only import one module per statement. C 2003/2/10
Feb 09 2003
prev sibling parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374389659766782 news.digitalmars.com...

 But then again, I also think that it's better to think in terms
 of modules and packages rather than files and directories. It's
 more abstract.

After all, something like "string.utils.unicode" can be used by the compiler in different systems to find its files in one of many different ways: looking in an index file, looking in a directory hierarchy, heck, "string.utils.unicode" is a valid filename in many systems today, so why not use it like that, either? As long as each module is in its own file, and the compiler has a way to find it, the rest is implementation details. Salutaciones, JCAB
Jul 02 2002
prev sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374364869616319 news.digitalmars.com...

 On Fri, 28 Jun 2002 10:34:13 -0700 "Juan Carlos Arevalo Baeza"
 <jcab roningames.com> wrote:

    The bottomline is that it would be best if paths were normalized to


 forward-slashes only. But that's bad for Windows. I don't think there's


 Why is it bad for Windows? It works, after all...a

For example: Have you never copy-pasted a path from an explorer window's address toolbar? Or from the file properties dialog? Or from a thousand other different places? They all come with back-slashes... In general, it's bad when you want to transfer a path from another program or file. I do that often enough. Salutaciones, JCAB
Jul 01 2002
parent Pavel Minayev <evilone omen.ru> writes:
On Mon, 1 Jul 2002 10:23:08 -0700 "Juan Carlos Arevalo Baeza" 
<jcab roningames.com> wrote:

    For example: Have you never copy-pasted a path from an explorer window's
 address toolbar? Or from the file properties dialog? Or from a thousand
 other different places? They all come with back-slashes...
 
    In general, it's bad when you want to transfer a path from another
 program or file. I do that often enough.

Since I do almost everything in console, I don't really use explorer address field or file property dialog that often. =) Besides, you get an absolute path, which is not suitable anyhow, and you have to strip it - so why not replace \ with / as well. .. or write a preprocessor script (gema rules!).
Jul 01 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:afhnhj$1qkr$1 digitaldaemon.com...
 Personally I do not see why all OS'es, Windows as well
 as all the others don't just make both characters valid?

The reason that Windows is backwards is because in the bad old DOS days, Microsoft decided to use / as the switch character, rather than -. (The / is used as a switch in DEC operating systems, which DOS mimics.) Then, when subdirectories were added in DOS 2, Microsoft was stuck, and so decided to use \ for the path separator. It's caused problems ever since. Many Windows programs and some operating system APIs do accept both \ and /, but support is erratic and unreliable. What Microsoft should have done is deprecate the / as a switch when they came out with NT, but they missed that opportunity, and XP continues to use / as a switch.
Jul 02 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:afeolg$tnn$1 digitaldaemon.com...
<SNIP>
 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

 in a different place - and on one it is completely absent.

 C 2002/6/27

So buy a decent keyboard! ;) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jun 28 2002
parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
OddesE wrote:
 
 So buy a decent keyboard!  ;)

<rant> I have a decent keyboard, however I also have a laptop - can not change the keyboard on that. Then I use the university computers, can not change the keyboards on them. And finally I use some computers which do not support the standard pc keyboard (SPARCstation, Amiga, Atari, others - no luck there either). This is a common problem with the backspace key, normally I would expect the back slash to be left of the Z key - however I can not assume that, which is a real pain in touch typing. What is easier creating a standard on new keyboard placement of the backslash key then replaceing all old keyboards or avoiding the problem all together and using a forward slash or a colon. By the way early versions of DOS allowed a choice of directory selectors. It was only a bad design decision in DOS 1 which caused a second bad decision in DOS 2: that \ was selected not /. Thats what you get for not thinking out a system properly. I have no idea why this feature was removed in later versions - it is not as if the forward slash is commonly found in file names. Finally the backslash should be used as an escape - as it is in every other place in the language. How else would we for example code import a\ file\ name\ using\ spaces without using the backslash. (Ok I know we could do import "a file" - but this is a rant so ignore the inconsistancies). DOS/Windows will not last for ever (though I have no idea of what will replace it currently), we should break the chain of bad design decisions made in yesteryear. I need a cup of tea. </rant> C 2002/6/28
Jun 28 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
On Sat, 29 Jun 2002 05:19:16 +0100 C.R.Chafer 
<blackmarlin nospam.asean-mail.com> wrote:

 By the way early versions of DOS allowed a choice of directory selectors.  
 It was only a bad design decision in DOS 1 which caused a second bad 
 decision in DOS 2: that \ was selected not /.  Thats what you get for not 
 thinking out a system properly.  I have no idea why this feature was 
 removed in later versions - it is not as if the forward slash is commonly 
 found in file names.

Well, DOS/Wind0ze do support / instead of \ in pathnames, so what's the problem?
Jun 28 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:afi1kq$2542$1 digitaldaemon.com...
 OddesE wrote:

 So buy a decent keyboard!  ;)

<rant> I have a decent keyboard, however I also have a laptop - can not change

 keyboard on that.  Then I use the university computers,  can not change

 keyboards on them.  And finally I use some computers which do not support
 the standard pc keyboard (SPARCstation, Amiga, Atari, others - no luck
 there either).

 This is a common problem with the backspace key, normally I would expect
 the back slash to be left of the Z key - however I can not assume that,
 which is a real pain in touch typing.

 What is easier creating a standard on new keyboard placement of the
 backslash key then replaceing all old keyboards or avoiding the problem

 together and using a forward slash or a colon.

 By the way early versions of DOS allowed a choice of directory selectors.
 It was only a bad design decision in DOS 1 which caused a second bad
 decision in DOS 2: that \ was selected not /.  Thats what you get for not
 thinking out a system properly.  I have no idea why this feature was
 removed in later versions - it is not as if the forward slash is commonly
 found in file names.

 Finally the backslash should be used as an escape - as it is in every

 place in the language.  How else would we for example code
         import a\ file\ name\ using\ spaces
 without using the backslash. (Ok I know we could do import "a file" - but
 this is a rant so ignore the inconsistancies).

<g> :)
 DOS/Windows will not last for ever (though I have no idea of what will
 replace it currently), we should break the chain of bad design decisions
 made in yesteryear.

 I need a cup of tea.

 </rant>

 C 2002/6/28

I am just saying that because some keyboards suck, we shouldn't depend on that for changes to the language. Someone on this forum complained about the ~ (tilde) being used in destructors and as a concatenation operator... Let's just not buy crappy keyboards that don't have certain keys. Especially when they are as important as the backslash! [RANT] That keys change place is stupid I guess, but it seems unavoidable. 'Innovation' in keyboard design demands that...*ironic voice*. I especially love the new keyboard design where the left shift is allmost as small as a normal character. Smart thinking! I *never* use the right shift, but that one is as big as a house, but the left shift, which I use three times every sentence and even more when programming has been shrunk to the size of an ant... :( And what about caps-lock...Why is it that IDIOTS WHO TYPE USING ALL CAPS get rewarded with a special key to aid them in their moronic behaviour? I *never* use the caps-lock key, but every once in a while I hit it by accident (actually because that ^%$% left shift key is so damn small) and I type half a sentence in all caps...Which I then have to retype. Hell, MS Word even has a special function to correct this misuse of caps-lock, that has got to say something!... One employee in my firm even 'disables' (breaks :) ) the caps-lock key on the keyboard he uses, just because he keeps hitting it by accident. If they could just get rid of caps-lock all together, and replace it with a HUGE shift key, now *that* would be innovation... :P [/RANT] -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jun 29 2002
parent "anderson" <anderson firestar.com.au> writes:
Very Amusing ;)

As most people know, typewritters were designed (well re-designed) to make
life slower for the average typest. I guess keyboard-dawdling technology is
jumping in leaps and bounds over the past few years. They're much better at
making our life harder then 50 years ago.

 [RANT]
 That keys change place is stupid I guess, but
 it seems unavoidable. 'Innovation' in keyboard
 design demands that...*ironic voice*.
 I especially love the new keyboard design
 where the left shift is allmost as small as
 a normal character. Smart thinking! I *never*
 use the right shift, but that one is as big
 as a house, but the left shift, which I use
 three times every sentence and even more when
 programming has been shrunk to the size of an
 ant... :(

 And what about caps-lock...Why is it that
 IDIOTS WHO TYPE USING ALL CAPS get rewarded
 with a special key to aid them in their
 moronic behaviour? I *never* use the
 caps-lock key, but every once in a while I
 hit it by accident (actually because that
 ^%$% left shift key is so damn small) and I
 type half a sentence in all caps...Which I
 then have to retype. Hell, MS Word even has
 a special function to correct this misuse of
 caps-lock, that has got to say something!...
 One employee in my firm even 'disables'
 (breaks :) ) the caps-lock key on the keyboard
 he uses, just because he keeps hitting it by
 accident. If they could just get rid of
 caps-lock all together, and replace it with
 a HUGE shift key, now *that* would be
 innovation... :P
 [/RANT]


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

Jun 29 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:afeolg$tnn$1 digitaldaemon.com...
 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

 in a different place - and on one it is completely absent.

When I recently replaced my keyboard, the new one had the [Enter] key with a bulge on the top that replaced the \ key. This caused me no end of grief, because I'd mean to type things like: rm foo\abc.def but would hit enter instead of the \, resulting in: rm foo which would wipe out the directory. Similar disastrous problems happen with the copy command and several others. After a week of this, I finally scrounged around till I found the older style (from IBM) with the small [Enter] key and the \ in the right place!
Jul 02 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:afsjbo$2bud$1 digitaldaemon.com...
 "C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
 news:afeolg$tnn$1 digitaldaemon.com...
 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

 in a different place - and on one it is completely absent.

When I recently replaced my keyboard, the new one had the [Enter] key with

 bulge on the top that replaced the \ key. This caused me no end of grief,
 because I'd mean to type things like:

     rm foo\abc.def

 but would hit enter instead of the \, resulting in:

     rm foo

 which would wipe out the directory. Similar disastrous problems happen

 the copy command and several others. After a week of this, I finally
 scrounged around till I found the older style (from IBM) with the small
 [Enter] key and the \ in the right place!

Ooow that does sound serious indeed. Sometimes I think these keyboard manufacturers do not use them to actually type something....doh... I hate the caps-lock, stuck between the very usefull left shift and tab keys. I hit it by accident all the time. Also what does the scroll-lock key do? Is that for console mode or something? I used to hate the Windows key, but nowadays I actually like it and use it a lot. If they could just put an LCD screen where the Num-lock, Caps-Lock and Scroll-lock indicators are (or just below it) and add a Calc-lock key which would activate a calculator, now *that* would be usefull! (I use the Windows Calculator all the time, but hate the fact that I have to start the program each time, or keep it running all the time. It just seems adding a small LCD screen would be *very* easy...) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 02 2002
parent Karl Bochert <kbochert ix.netcom.com> writes:
On Tue, 2 Jul 2002 23:28:46 +0200, "OddesE" <OddesE_XYZ hotmail.com> wrote:
 I hate the caps-lock, stuck between the very
 usefull left shift and tab keys. I hit it by
 accident all the time.

I finally got to the point where I take my keyboards apart and remove the little rubber doo-hickey under the caps lock key. Prying off the keycap almost works.
Jul 03 2002
prev sibling parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
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

Surely something similar is being done with the arrangement of modules into packages, with a suitable package managment tool - as opposed to a file manager - the effect would be much the same. (the package manager would allow modules to be moved around in the source tree thereby allowing 'import libs.library.myLibary' to be written 'import libs.myLibrary' after myLibrary has been moved). The only improvement I can see with your system is that this should be easier to implement. However I see a disadvantage in that either the scope resolution rules would either need to the altered or we would need a slightly different syntax to declare the import ie. import em = engine/mathematics; import dmp = phobos/mathematics; or maybe import engine/mathematics module em; (though the latter option is rather to verbose for many people). C 2002/6/28
Jun 28 2002