lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, Jun 24, 2016 at 2:32 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> [1]
> Tables have individual metatables. Tables freshly constructed
> by a table literal have none. The following is an error:
>
>> ({24,6,2016):concat"/"  --> (not yet) 24/6/2016
>
> Would it not be nice if tables that have no metatable fall back
> to {__index=table}? [2] Only table.pack does not have a table as
> first argument, and we have a precedent for that in 'string',
> which is also the __index of a metatable but contains functions
> cannot be used with object notation.

I almost posted this [1] to the __next thread:

<quote>
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.
:)
</quote>

[1] http://lua-users.org/lists/lua-l/2014-08/msg00194.html


-- 
Patrick Donnelly