[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: String indexing again
- From: Axel Kittenberger <axkibe@...>
- Date: Mon, 20 Dec 2010 22:27:31 +0100
"A string that doesnt support indexing"
sorry that should read,
"An array that doesnt support indexing"
On Mon, Dec 20, 2010 at 10:26 PM, Axel Kittenberger <axkibe@gmail.com> wrote:
> 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)
>