RE: Just say 'OF' to strings
- Posted by "Patrick Barnes" <mistertrik at hotmail.com> Jun 03, 2004
- 411 views
As far as I can see, this whole debacle (and yes, this wording is intentional) revolves around the ability of Euphoria to recognise that a sequence of characters is a string, and that a sequence of arbitrary values is not... 1. If strings are desired for a smaller memory footprint, a smaller footprint is not possible if unicode strings are to be supported. The band_aid solution of adding yet *another* native type; the U_STRING, will exponentially compound the problems with increasing the number of native types. 2. If a string is desired to get away from the interpreter printing out the string in { , , , } form accidentally... 2a. First of all, for any singular variable, you should *KNOW* what whether the variable is a generic sequence or a string, and use print and puts accordingly. If you want strings to display nicely in the trace window, Rob is implementing new functionality in upcoming versions of Euphoria to allow the community to write their own trace windows. I would think that you could quite easily create some 'sticky' options within the new tracers that could display sequence variables as strings, arrays of strings, etc, and even reverse polish notation if you had the inclination. 2b. Secondly, if you have a large sequence with generic values, where the type of each value is not known in advance... I'd say that's BAD programming. Yes, you cannot differentiate between string and generic sequence, but you can't differentiate between an integer, and an atom that just happens to be a whole number, or any two custom types that may be able to fit into each other - eg 3d_vector and rgb. If you want to do something like that, have a prefix to each type with an integer constant identifying it. ie: { {INT, 5}, {STRING, {50, 48, 77, 29} }, { SEQ, {50, 48, 77, 29} }, {3D_VEC, {50, 48, 77}, {RGB, {50, 48, 77} } Y'see what problems could arise without these prefixes? The only way out of that would be to apply rigid casting to *everything*, and that would really screw things up. Adding a "STRING" type will not fix ANYTHING. Consider another problem: if you pass a literal to a function accepting a value of object, what type does that object hold? Is it a sequence, or a string, or both, or neither? What??? I think that the string type would not be necessary for the purposes above. If you want to ensure that a sequence remains compatible with the idea of a string, and does not inadvertently contain invalid data inside it, support the drive for "OF"! :o) MrTrick