[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: 'table' as fallback for tables
- From: Patrick Donnelly <batrick@...>
- Date: Fri, 24 Jun 2016 16:53:06 -0400
On Fri, Jun 24, 2016 at 3:59 PM, Soni L. <fakedme@gmail.com> wrote:
>
>
> On 24/06/16 03:52 PM, Patrick Donnelly wrote:
>>
>> 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,
>
> So how do you copy a table's contents?
Well, (without pairs) you would do (just as in normal Lua):
for k,v in next, t, nil do
t2[k] = v
end
but if you have table.map|array*, then you can do:
local t = setmetatable({}, table.map)
for k,v in t do
t2[k] = v
end
* I haven't seriously thought if table.map|table.array would be best
exposed as a metatable or as a factory. A factory could protect the
metatable to hide the raw __next metamethod.
--
Patrick Donnelly