Re: __methcall

[Mark Hamburg <mhamburg@...>]

on 11/4/04 9:58 AM, Daniel Silverstone at dsilvers@digital-scurf.org 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.

Mark