Re: metatable transmission

[Mark Hamburg <mark@...>]

On Dec 23, 2009, at 8:59 AM, Roberto Ierusalimschy wrote:

>> On Dec 22, 2009, at 11:25 AM, Javier Guerra wrote:
>> 
>>> On Tue, Dec 22, 2009 at 2:16 PM, spir <denis.spir@free.fr> wrote:
>>>> Again: why aren't metamethods identified by name?
>>> 
>>> you keep repeating this; but i really don't get what you mean.  either
>>> you defined your request somewhere else and i missed it, or you think
>>> it's too obvious to state.  but i _really_ don't have the faintest
>>> idea what this could mean.
>> 
>> I think what Denis is asking is why we can't just do things like put
>> __tostring in the object/table itself and instead we have to put it in
>> the metatable.
> 
> You can. Just set the table as its own metatable.

Good point. I haven't seen that pattern all that often, but it certainly does work and it avoids the need to create lots of pieces to build an object.

>> That would certainly make one-off object creation easier. I don't know
>> what the performance impact would be in general and I don't know what
>> the other considerations were that led to the current design.
> 
> I think one-off objects are the exception, not the norm. For what seems
> to be the normal case (many objects sharing one or more metamethods), a
> separated metatable may be a great saving.
> 
> In the beginning, "index" and "newindex" (then with different names)
> could not be tables, only functions, so sharing metamethods was even
> more common. People did not mind paying the price of a function call for
> a table access: that was the standard price.
> 
> Then Lua introduced the possibility of tables in "index" and "newindex".
> Suddently, the price of a function call became prohibitive. Of course it
> is exactly the same price, but comparatively it was too expensive. Now
> most programmers avoid using functions for "index" and "newindex"
> metamethods. A change that was supposed to speedup a special case ended
> up restricting the flexibility of the language.

Thanks for that bit of history.

Another way I've been thinking about trying to explain metatables is that if you ignore __index and __newindex and ignore colon-syntax message sends, then there's a relatively clear picture in which the table is about content and the metatable is about behavior (__add, __tostring, __call, etc.). Adding back in message sending means that some behavior may come from the table itself. Adding back in __index and __newindex -- particularly in their table forms -- means that some content is now tied to the metatable.

Mark