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.


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



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.


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.


   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.


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


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.


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


problematic

 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


dammit.

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






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






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




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


separator

 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




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


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>


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.


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>


 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.


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




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


   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


is

 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


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


<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


is

 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


 is

 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!


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