Re: __methcall

[Mark Hamburg <mhamburg@...>]

When I hooked up something more or less equivalent to what you've done, I
also allowed it to be used with Lua data.

The reason I proposed restricting this to userdata was that doing so avoids
the semantic issues related to inheritance hierarchies -- Do you need to
wire up both the methods and the field access? How do they intertwine when
going through multiple levels? -- and provides support in the case where it
seems most critical which is making it easy to provide safe methods for
userdata. Table-based objects will never be completely safe as long as one
can directly access the tables.

Mark

on 11/4/04 4:58 PM, Daniel Silverstone at dsilvers@digital-scurf.org wrote:

> On Thu, 2004-11-04 at 10:38 -0800, Mark Hamburg wrote:
>> For userdata, and userdata only, OP_SELF would be defined as looking for a
>> __getmethod metatable entry before trying __index. (I chose the name
>> __getmethod rather than __methcall since it doesn't actually do the call.)
> 
> Bad call. I assert that it is useful for pure lua too. In fact it's
> almost 100% necessary for the class system I'm putting together. The
> naming of it __getmethod is certainly better than my original __methcall
> but I think I prefer __method to be consistent with __index
> 
> [snip rest]
> 
> the lua_getmethod() thing you suggested I think would be far better
> served with something more like.
> 
> Given object at index obj
> 
> lua_pushstring(L, "foomethod");
> lua_pushnumber(L, 12);
> lua_pushstring(L, "otherarg");
> 
> lua_mcall(L, obj, 2, 1); /* call a method in obj given two arguments and
> the method before them. return one value */
> 
> Then provide the obvious gamut of lua_pcall etc with the 'm' variant for
> added happiness :-)
> 
> D.