Re: String indexing again

[Axel Kittenberger <axkibe@...>]

This

> --s[n] returns string, you want value:
> The former case seems more convenient and cleaner;

conflicts with thihs:

> In Lua as
> well sometimes a string will not contain text, but just function as an
> array of bytes read from/written to a binary file. (This is perhaps
> another argument for allowing indexing?)

Since then an index should return a byte.

To refer to the OP, if you shoot at the manual, I'd go for this
sentence, In 2.2 "String represents arrays of characters.". A string
that doesnt support indexing, [] in other languages called "the array
operator" is an oxymoron. Would better say, "String represts
_sequences_ of bytes. (signed or unsigned, what I see Lua code
converts between (char) and (unsigned char) depending on context forth
and back). Also Lua doesnt know about "chars".

You are right. Strings are not necessarily text or an array of
characters, since they are also used for binary data. In that case
they are more a interned "binary object". I also agree
force-converting everything to one format like PHP isn't a good idea.

And looking at strings with dynamic sized chars, and binary data, the
workings of the index method should be different for both - another
argument against a standard index default.

Somehow I wish, one could change the metatable of a particular string,
or a kind of strings. Instead of one metatable for all strings... But
I suppose aside from implementation this conflicts from concept
already with interning.

> Also maybe worth considering: Should files allow numeric indexing,
> treating them as giant on-disk byte arrays? I usually wrap mine in a
> metatable that does just that; e.g. f[3] = 3rd byte of file.

Not all files are seekable. (Especially e.g. the Linux notion of
character devices as files)