Re: table.maxn...

[Coda Highland <chighland@...>]

On Sun, May 31, 2015 at 12:58 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On May 30, 2015, at 8:55 PM, Coda Highland <chighland@gmail.com> wrote:
>>
>> In practice, using maxn is almost always a mistake. It has inferior
>> performance (and the bigger your table is, the worse the gap gets) and
>> any design where you care about the difference between a sequence and
>> a non-sequence and you don't know in advance which you're looking at
>> is dubious at best. Seriously, if you're dealing in sequences, then
>> you ought to know you're dealing in sequences, at which point you
>> should be using #t for the performance. And if you're dealing in
>> arbitrary tables that may or may not be a sequence, you shouldn't be
>> trying to treat them as sequences at all, but rather explicitly
>> tracking a length or something.
>
>
> As I’ve said before, all this is true *if* you have control of the entire
> set of Lua code running. It’s not clear to me how an author of a library/API
> that consumes a sequence can efficiently ensure that he is passed a valid
> sequence. Of course, the API could just assume validity and fail in
> unexpected ways, but I don’t regard this as good API design.

I accounted for that in the very message you replied to -- IF you
don't know for sure that you're processing a sequence, THEN you should
be doing something different.

It's not bad API design to put a precondition on an exposed function.
In fact, it's one of the classic maxims of programming: Garbage In,
Garbage Out. Should I be checking type() on my incoming parameters to
make sure they're tables before I index into them? Or should I skip
the check, and if it breaks that's the user's fault?

Sequences are a well-defined part of Lua. Lua's own functions expect
proper sequences if you want well-defined behavior. Expecting a
third-party library to accept an object that the native functions
won't handle is asking too much.

/s/ Adam