lua-users home
lua-l archive

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


Ah. Thanks for the feedback on that! I am going for a simpler solution
as of now, which is just to test for presence of a metatable.

When I create Lua objects these days, I am lazy and just put the
methods in the table directly. I don't know if it was smarter to do it
any other way, but it's convenient and it works. Probably memory
efficiency would be the main reason to collect things in common
metatables, right?

Cheers,
Stefan

On Tue, Aug 23, 2011 at 4:08 PM, Dirk Laurie <dpl@sun.ac.za> wrote:
> On Tue, Aug 23, 2011 at 03:24:34PM +0200, Stefan Reich wrote:
>> My question arises when tables are sent as method arguments. There are
>> two cases:
>>
>> -It's a plain table. Then it should be copied to the receiving sandbox.
>> -It's an object. Then it should be passed by reference to allow remote calling.
>>
>> The question is: How do I distinguish a table from an "object"? There
>> is no clear-cut difference in Lua as far as I understand.
>
> The difference is this: 'table' is a Lua type. 'object' is not:
> it is only a style of programming.  You have the privilege and the
> responsibility to define what you mean by 'object'.
>
> For instance, you might consider something to be an object if all
> functions that are intended to access it, sit inside its metatable.
> No way of testing that, though.
>
>> My current solution is to consider a table an object if it contains
>> only functions. But maybe you just want to pass an array that happens
>> to contain a function. (Function references are also possible.)
>>
>> Maybe it would make sense to consider anything with a metatable (even
>> if the metatable is empty) an object and anything without a metatable
>> a table.
>>
>
> If you take PiL §16.1, §16.2 as your model for object-oriented
> programming, the following property is a possible definition:
>
>    function isobject(a)
>        local mt = getmetatable(a)
>        return mt and mt.__index == mt
>        end
>
> Dirk
>
>