lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I think the way I would approach this ipairs thing would be to move all of the raw* functions to a raw.* library, with raw.set(tbl, k, v), raw.ipairs(t), raw.equals(a, b) and so forth. Then ipairs() would clearly iterate over the length of the array portion as stored in C, which should both be apparent from the name, and more predictable w.r.t. performance. In addition you clear up the main namespace and it's clear that these functions do not interact with metatables.

__ipairs, and for that matter __construct and __sort, are basically duplicated functionality from __len and __call / __lt, respectively. It's hard (for me) to imagine a situation where using both such (corresponding) methods, differently, would solve a problem without making code unnecessarily confusing and opaque.


On Thu, Aug 7, 2014 at 12:55 AM, steve donovan <steve.j.donovan@gmail.com> wrote:
On Wed, Aug 6, 2014 at 9:46 PM, Jay Carlson <nop@nop.com> wrote:
> Admittedly I get sick of writing v{1,2} + v{3,4} sometimes, but when I
> really get sick of it I'm halfway to writing a mini-language anyway.

Which is about as minimal as syntax gets.  Otherwise I would have to
worry about every single table constructor in case a custom
constructor has been defined globally.  And it's exactly the kind of
thing that leads to fights ;)