Re: ipairs in Lua 5.3.0-alpha

[Patrick Donnelly <batrick@...>]

On Mon, Aug 4, 2014 at 10:16 PM, Coroutines <coroutines@gmail.com> wrote:
> On Mon, Aug 4, 2014 at 6:44 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
>> 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.
>
> 1) I don't like raw*() -- I wish we had a debug.raw(self, metamethod_name)

I agree on raw*. It violates any sort of interface a developer might
build for e.g. a class. It's basically the same as messing with the
upvalues of a function, as if debug.setupvalue were setupvalue. If Lua
takes measures to protect *its* interface/mechanism, it should also
protect the developers'.

This actually brings to mind the (IMO) evil and prevalent use of
lua_rawseti/lua_rawgeti in the Lua table library. If I build a
read-only table via a proxy, the table library can be used to shadow
array values by changing the proxy. I believe the lua_rawseti and
lua_rawgeti are favored due to their interface, not because they
bypass metatables. There really should be a similar friendly interface
for non-raw geti/seti.

> 2) I wish __pairs/__ipairs were added back,

I never liked those.

> I also want __type,

Same.

> and
> __sort -- while still having the ability to override the __sort with
> the method passed to table.sort() as the 2nd arg,

I think the normal argument against this is you could provide your own
sort method. Why change how table.sort behaves (which is intended to
only operate on arrays). The same argument is used against __type, and
indeed, Lua's file:type() exists to encourage this approach.

> and a __next would
> be awesome for C objects exposed to Lua

I like __next as well because it closes yet another hole that violates
metamethods, provides a metamethod mechanism that didn't exist before,
and could pave the way for iterable objects again in Lua:

for i, v in array do
end

Hell, then the standard library could have:

table.array = {__next = ipairs_aux, __index = table} -- ipairs_aux
from lbaselib.c
table.map = {__next = pairs_aux } -- pairs_aux from lbaselib.c

Users could then:

t = setmetatable({}, table.array)
-- ...
t:insert("foo")
-- ...
for i,v in t do
  -- ...
end

[It would also be appropriate to move next to rawnext/debug.rawnext.
Also, because __metatable protects the metatable, a user can't just
change an object's metatable to table.map to violate your
abstractions.] Imagine a world where pairs/ipairs no longer existed.
:)

-- 
Patrick Donnelly