Re: ipairs in Lua 5.3.0-alpha

[Tim Hill <drtimhill@...>]

On Aug 4, 2014, at 1:48 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

>> is the metamethod model in Lua getting more complicated (as opposed to complex)?
> 
> I don't think so. If you, like me, make a distinction between core
> metamethods and library metamethods, then the core metamethods are
> simple and reflect the semantics of Lua, while library metamethods are
> some how expected to have to interact with each other and with other
> library functions. Witness the recent postings about which library
> functions should honor __tostring and how __pairs and __pairs should
> behave, especially in the presenceof len metamethods. From this comes
> complications and complexity...
> 

Yes, I agree and I’ve always distinguished between low-level __add/__lt/__index etc and high-level __ipairs etc. In fact I think the docs should emphasize the difference between these. To my mind, the low-level metamethods should always be honored except when explicit “rawXXX()” Apis are used to bypass them, which is why I like the change in 5.3.

As for __pairs() and __ipairs(), to my mind pairs() and ipairs() should always have been generic algorithms with (perhaps) the ability to over-ride. Which, of course, brings up the question of table.sort() .. is this now really a generic sort, and thus actually a global function hiding, somewhat arbitrarily, in the table library? You can see where this is headed, I’m sure: “sortable” things are items that implement the necessary metamethods. I don’t know if i like this, but that seems to me the way things are drifting as Lua makes more consistent use of metamethods.

—Tim