Re: Lua, LuaJIT2 and differences with the length operator

[Leo Razoumov <slonik.az@...>]

On Tue, Jan 4, 2011 at 11:58, Tony Finch <dot@dotat.at> wrote:
> On Tue, 4 Jan 2011, Leo Razoumov wrote:
>>
>> And how exactly I am supposed to do this job? E.g., how can I test
>> that an array  t coming my way from someone else's library has no
>> holes?
>
> Two options:
>
> 1: Don't bother. It's the caller's responsibility to obey your API
> requirements.
>
> 2: Give your tables a metatable that keeps track of the invariants you
> require, if they don't match the ones provided by Lua.
>
> Tony.

Option 1: does not help here. "Donot bother" is another way of saying
that the language does not help you here and that one needs to rely on
some other "out-of-band sigalling" mechanisms to achieve desired
behavior.

Option 2: is not applicable if the table in consideration comes from a
third party library and could already have metatable associated with
it for totally unrelated reasons.

I am fine with the way #t operator is defined. It is logical and
consistent. My problem is different. I cannot see a good way to tell
when it is safe to trust #t and when not (longing for table.has_holes
test)

--Leo--