1. Suggestion for Fileman.e
Another Suggestion for Fileman.e
I suggest the following for a future version of fileman.e.
How about using the next 255 bytes after the 255 length bytes,
to indicate the types of the 255 possible fields in the file.
We could let 0 be a Euphoria object, 1 be a sequence, 2
be an atom and 3 be an integer. Then, if other field types
are needed, you could define another 254 of them. I imagine
that would suffice for most purposes. This would allow the
checking of field types both on input and output.
Now, for example, if someone were to create a time or date
field type, they could easily incorporate the code into
Mr. Jackson's routines, or better still, send the code to
Brian and let him test and integrate it into his code. He
could then assign a permanent field type number, which would
be available to all Euphorians!
I know that Dbase stores the names of each field in the header.
This is a possibility and I can see utility here.
Someone discussed the Dbase commands, such as PACK. It seems
to me that the SQL is more common and perhaps easier to
implement?
Larry Gregg
2. Re: Suggestion for Fileman.e
- Posted by Daniel Berstein <daber at PAIR.COM>
Mar 06, 1999
-
Last edited Mar 07, 1999
At 12:06 PM 06-03-1999 , you wrote:
>Someone discussed the Dbase commands, such as PACK. It seems
>to me that the SQL is more common and perhaps easier to
>implement?
SQL is more complicated to implemet because you have to parse que SQL
statement. The "interpreted" SQL statement then is executed as if you would
have harcoded the native commands (seek, read, etc.).
I would love to see an SQL parser in Euphoria.
Regards,
Daniel Berstein
[daber at pair.com]
3. Re: Suggestion for Fileman.e
- Posted by Brian Jackson <bjackson at PRINTINGINC.COM>
Mar 06, 1999
-
Last edited Mar 07, 1999
On Sat, 6 Mar 1999 11:06:32 -0500, lgregg at BIG12.METROBBS.COM wrote:
>How about using the next 255 bytes after the 255 length bytes,
>to indicate the types of the 255 possible fields in the file.
>We could let 0 be a Euphoria object, 1 be a sequence, 2
>be an atom and 3 be an integer. Then, if other field types
>are needed, you could define another 254 of them. I imagine
>that would suffice for most purposes. This would allow the
>checking of field types both on input and output.
Larry,
Thanks for your suggestion. The way FILEMAN is written now, it makes no
assumptions about what kind of data a program will read or write. I can
definitely see the usefulness of assigning type to fields, but it seems
to me that there would be a lot of overhead associated with that. Another
problem would be that if a type-check error occurred, there is no way to
trap it from within FILEMAN.
For now, I think I'll table your idea and see how some 'real-life' programs
has to deal with some of the issues yet to be ironed out with FILEMAN. If
working with numeric fields (for example) ends up to be a big pain in the
neck, I may incorporate something similar to what you've suggested.
BTW, I have to agree with Daniel regarding SQL. I've already been modeling
some of my code after xBase, and probably shouldn't change horses in
mid-stream.
The next release of FILEMAN is almost ready. All I need to do is write
and debug a short demo, and then it will be ready for testing.
Thanks again,
Brian Jackson
bjackson at printinginc.com
