lua-users home
lua-l archive

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

on 11/4/04 9:58 AM, Daniel Silverstone at wrote:

> On Thu, 2004-11-04 at 09:43 -0800, Mark Hamburg wrote:
> [snip concerns and comments]
> I think the easiest way to answer the questions regarding my patch is to
> simply say..
> __methcall first, then __index, then the table itself

But what about entries in the table itself? Do those trump __methcall?

> I.E. the idea was simply to (while remaining utterly
> backward-compatible) offer a way to move the methods out of a directly
> indexable mechanism.
>> The big benefits of __methcall seem to be:
>> * Easier support for safe userdata method invocation since methods can't be
>> pulled off of one object and used on another. I could see a case for
>> supporting __methcall just for userdata.
> The only way this becomes safe is if you go with the
> foo:bar(...)  ::= getmetatable(foo).__methcall(foo,"bar",...)
> otherwise you can extract methods with
> getmetatable(foo).__methcall(foo,"bar")
> Personally I don't think it's a question of "hiding" or "making safe" --
> I think it's far more a question partitioning the namespace a little

Protected metatables make this work. If the metatable is protected then,
__methcall only gets invoked from OP_SELF and hence the function can't leak
into the general environment. This means that userdata then doesn't need to
type-test the first parameter on method calls if it exposes it's methods via
__methcall in a protected metatable.