Re: metatable transmission

[Mark Hamburg <mark@...>]

On Dec 22, 2009, at 9:11 AM, Mark Hamburg wrote:

> On Dec 22, 2009, at 3:35 AM, spir wrote:
> 
>> I still have a question about metatables, rather about a language design choice. Metamethods are identified through table _key_ names, which builds an indirection (and imo complicates the model). This in particuliar forces metamethod be held in another table, namely the metatable. Why not, like in several other languages, identify metamethods directly by their _own_ name?
>> The result seems to be that metatables must be copied, if only to allow further customization (in addition to other things to do at type/instance creation time). In the simplest case, when copying an object one must not forget its metatable... I'm surprised about the overhead, too, because people in the Lua community seem (even more) obsessed with machine performance.
>> Without the indirection introduced by such a model, only generic behaviour methods needs be copied (actually references only, as you say it), not key-pointers to them (in an external metatable).
>> I guess there is a certain advantage for Lua's model, but I am unable to find it myself (except for not polluting type/object namespace, but in practice this argument does not hold.)
> 
> The fundamentals of prototype-oriented, metatable-based design are probably that you should start out by thinking of your object as having three parts:
> 
> 	The primary table
> 	The metatable
> 	The __index table

One thing I will say is tricky in this model: It is difficult to set a field to nil if it is supplied in the __index table. The simplest solution in that case is to have a __newindex method that detects this operation and transfers the entire __index table to the primary table and severs the tie to the __index table. One could also envision cloning the __index table and just removing that entry, but that isn't particularly pretty either.

There are times when I miss JavaScript's distinction between nil and undefined. One could argue that the problem would then just resurface with a need to replace values with undefined, but I suspect that one level of "not present" support would push the remaining cases to the extreme fringes.

Mark