[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: __methcall
- From: Mark Hamburg <mhamburg@...>
- Date: Thu, 04 Nov 2004 10:26:55 -0800
on 11/4/04 9:58 AM, Daniel Silverstone at email@example.com 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
> 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.