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

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

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?

"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

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

"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

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

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

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.

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