Re: One last shot at Namespace and Structure
This first desire of fixed length fields is easily obtainable.
I will see about creating some code to do just that in the near future.
If you know that all fields are fixed length then you can easily,
randomly read and/or edit any record without having to read the entire
file. Thus is the nature of fixed length fields and records.
Sincerely,
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow | ICQ: 9638898 | AIM: LLHIII | Computer |
| Horse +--------------+--------------+ Cafe' |
| Software | http://www.cdc.net/~lhilley | USA |
+----------+-------+---------------------+----------+
| http://www.ComputerCafeUSA.com |
+--------------------------------+
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, October 18, 1999 1:51 AM
Subject: One last shot at Namespace and Structure
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Everett Williams <rett at GVTC.COM>
> Subject: One last shot at Namespace and Structure
> --------------------------------------------------------------------------
-----
>
> I have spent the last several days reading everything that I could find on
> namespace and structure since January 1, 1998. There is a huge amount of
> quite thoughtful information in that span, and I am sure that Rob has
taken
> note of it, but I think that some of it has become so theoretical that it
> would be difficult to decide what is important.
>
> My basic wish is for this:
>
> A. Some means(can't use method here...might confuse) that will allow me to
> read one of the thousands of files in this world with fixed length records
> and fields, make changes and write it back out to a new file.
>
> 1. I don't care if it takes objects or classes or structures, but I
want
> to be able to use the same basic template(read here include) for the input
> and output files( because I probably will do it over and over again and
the
> files are structurally identical).
>
> 2. I want to be able to refer to the fields in the input and output
> records by name without using screwy numbered constants and without having
> to play strange games to separate the input fields from the output fields.
>
> 3. I would really like to be able to dynamically attach a name to any
> element in a sequence and have it usable from that point. But I will live
> without this one.
>
> B. I want to be able to use as many different libraries as I need without
> having to look at anything but their documentation(knowing that in some
> cases, I may not be able to look inside them anyway).
>
> 1. Whatever rules for precluding colliding includes are necessary, let
us
> enforce them in the interpreter...not depend on the good will and skills
of
> programmers at various levels of experience, however well intentioned.
>
> 2. If they are to be allowed to overlap intentionally, then give us
> precedence rules(I think we have most of these, already).
>
> 3. If we don't want them to overlap, then we should be able to prevent
> that at the include level, without acting or editing inside the include.
>
> 4. Dynamic includes would be really nice to allow programs to flexibly
> adjust themselves to platform or environment or user selection without
> contorted methods or including unneeded code to occupy the interpreter.
>
> C. The means to exclude some items from bind so that initialization files
> and other such items may be more easily implemented in bound code.
>
> All these items share a logical set of functions except for the last and
> that one comes from the same needs. Those needs are to be able to handle
> data from external sources quickly and easily and to program arbitrarily
> complex and large code sequences in as modular a manner as possible.
>
> However these items are accomplished, I will be happy. Of course, timely
> fulfilment wouldn't hurt my feelings :)
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
|
Not Categorized, Please Help
|
|
