1. Long File Name Support (was: Revised Namespace Proposal)
----- Original Message -----
From: "Bernie Ryan" <xotron at localnet.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Revised Namespace Proposal
> I feel this feature is of no advantage.
Fair enough, that's your opinion. Not mine though.
> If a user is using include files then they should be in the
> Euphoria include directory,
Why "should" they? Why don't you think that people should be allowed to
place include files in any directory that is suitable for their own reasons?
Why should we be made to follow RDS conventions?
> this directory is used for
> DOS so it probably doen't have spaces.
> If you are giving a client/user a compiled or bound Application
> then the application is going to be launched by/from
> windows ( which will the directory ).
What has this got to do with anything? I don't understand what you are
saying here, sorry.
> Some users have written install programs, Are they going to
> then use spaces in their install programs ?
Yeah, why not? What have you got against spaces? It seems that you are
arguing against the concept of spaces in directory names, not just it
support in Euphoria? What about multiple periods? DOS 8.3 restriction is so
artifical and limiting - that's why Microsoft decided that Unix, VMS,
AmigaDOS and a few others got it right and tried to catch up.
> What happens to the DOS users on the list that can only
> aford to use a version of DOS that doesn't supports
> spaces ?
Then they don't try to use spaces in file names.
> What happens if they create a directory with a
> space in it with Euphoria.
Then it means that the opsys supports spaces in directory names. What's your
point?
> I have been waiting on the list for 3 years for improvements
> to be made to Euphoria and I do not think that these kind of
> features should be added until more important features are
> added such as :
What "features"? We are talking about one single feature that is going to
cost less than a day for Robert to implement and test in all 17 varieties of
Euphoria.
> 1. a better foward references solution
Yes please. But I believe that Robert has his heart set against this
concept. It seems that it clashes with his philosophy of programming.
> 2. inline assembler
Which machine are we talking about - Intel, Motorola, Zilog, etc....
> 3. a easier interfacing to other langagues.
With what? Compiled (.EXE), object code (.OBJ), or source code (.C, .CPP,
.BAS, .COB, .P, ...) What do you have envisaged here? Euphoria calling code
written in other languages at run time? Having the translator link in .OBJ
files from other compilers? Having other programs call a Euphoria program at
runtime? Are we talking about COM and DCOM? or CORBA? or EJB? or what?
Each of the above is a non-trival exercise. They are definitely not "low
hanging fruit". And how many people will be using in-line assembly anyhow?
> Of course that is my opion whether anyone agrees
> with me I don't know.
I don't agree with this opinion.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
