At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote:Melvin Smith <[EMAIL PROTECTED]> wrote:At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:set I2, P1["Foo\x00i"] # I1 == I2
gets currently the attribute idx (0) of "$Foo::i". Q: Should the assembler mangle the "Foo::i" to "Foo\0i"
Why was this even needed in this example? Since P1 was the class Foo, why do we need scoping here--shouldn't the above just be:
set I2, P1["i"] # I1 == I2
Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic.
Yeah its ungly. OTOH it should be really transparent for all possible HLLs. And the NUL most certainly is.
I don't like it either, but the alternative is to impose an external hierarchic structure. Which we certainly could do, though it may make some things more difficult.
I'm more than willing to entertain arguments for and against the hierarchic structure, but we're closing in on the point where we fix the scheme and don't change it any more.
I don't see a big advantage of using a null byte over any other character--a null may seem unlikely to conflict with an HLL, but that's just hoping. If we're going to define a syntax, then we may as well make it easy to print out in the debugger, and use "." or ":", and either restrict identifiers to be underscore-letter-number combinations, or define an escaping syntax so that "foo\.bar.baz" means "baz" in the "foo.bar" namespace (ugly, but workable).
If we _really_ want these to be strings and reserve some special character, then we should pick something in the Unicode private use area. But either way, I think we need an escaping syntax, so that I can really have a null byte (or whatever) in the middle of something.
If we really want to allow the most freedom possible to HLLs, then these should be specified as arrays--no special characters needed. That is, "foo:bar:baz" in Perl code would assemble into an array of "foo", "bar", and "baz" (and "foo.bar.baz" in Java would assemble to the same thing). It would be natural then to store these in nested hashes, but not 100% necessary. I think this is what you meant by a hierarchic structure. It seems straightforward, though with some overhead. We could get around the need for hashes by defining an escaping scheme as mentioned above, but as an internal implementation detail--that is, the API uses arrays, but internally uses strings. Hiding that detail lets us change it later.
JEff
