1. Suggestion for Fileman.e
- Posted by lgregg at BIG12.METROBBS.COM Mar 06, 1999
- 350 views
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
- 347 views
- 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
- 346 views
- 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