Re: table.unpack(...) and the __index metamethod

[Andrew Starks <andrew.starks@...>]

On Sunday, June 15, 2014, Tim Hill <drtimhill@gmail.com> wrote:
> On Jun 15, 2014, at 3:02 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
> > My opinion is this: in cases where a metamethod might be respected or
> > not, the library routine should do that which is more often needed. If that
> > decision is not obvious, it should do that which is less neatly done in
> > plain Lua. Whenever the __index metamethod is involved, tbl[i] is neater
> > than rawget(tbl,i). Therefore the library function should be using rawget,
> > unless it can be argued convincingly that this is the unusual case.
> >
>
> So the logic is, table sort() may have complex semantics when metamethods are used, so table.unpack() should not use metamethods?
>
> First, there is a big difference between the two: one mutates the table the other does not. Second, I find your example contrived. The table.sort() function has defined semantics (comparing and swapping values). If the caller has constructed a metatable that means those sort semantics have a specific, albeit unusual, effect, then that’s the effect they have; caveat emptor. It should be noted that in your example table.sort() has equally peculiar behavior when used with raw get/set as well. Are you then arguing that table.sort() should be removed from the library entirely?
>
> The Lua docs are full of elegant ways to use metamethods with tables, many involving various forms of information hiding and abstractions. I do find it odd that, having expounded on their use, the standard Lua library then bypasses them most of the time. Particularly as, has been noted, they can be constructed in a way that has insignificant performance impact.
>
> Regardless, my original point stands: the stated justification for not using metamethods on table.unpack(), that of performance, does not appear to be the case.
>
> —Tim

This is stating something that is very obvious to you guys, but upon thinking about it, the distinction between the *table* library and a

non-existent library that works with tables + their defined behaviors, aka "objects", becomes important. The same holds for theath library, which also does not work with anything except numbers (or strings that can be numberfied). 

Assuming nothing about Lua were to change, I would find it clarifying, if I haven't missed something that is already present, if there was something that emphasized that distinction:

"Except for a few exceptions, Lua's standard libraries work with Lua's basic types and do not check for a metatable or metamethods, when manipulating or accessing them."

Another sentence or three on why this is the case and how these libraries may be built upon to handle "object-like" values, would be good, too. 

What is obvious to the designer or to the CSCI degree holder can look confusing and inconsistent to someone without mental access to the broader issues. 

-Andrew