Re: rethinking method calls with __mcall metamethod rather than __index/__call

[Steven Johnson <steve@...>]

> Finally, it makes it easier to write methods that can know to what object
> they are being applied because they can't be accessed as "loose" functions.
> That's a help when writing efficient bridges to native code.

With regard to "loose" functions, there's another point that's relevant to your
recent topics about key privacy, as seen from your example in [4] above:

   local cacheMethod = obj1.msg
   -- intervening code where you forget what's going on
   cacheMethod( obj2 )

One may "forget" what's going on and add an obj2 with its own __index and
/ or __newindex metamethods. Especially with little accessors that don't do
enough to fail, suddenly our keys aren't so hidden.

I use a key scheme like yours, so this has been on my mind. Maybe such a
metamethod would help shore this up.

(Per-member weak tables and stuffing each method with a type assertion are
the present solutions of which I'm aware. Are there others? I suppose if I ever
get around to using Metalua to auto-generate the keys I could have it add the
assertions too...)

> There should be discussion about whether this should first look at rawget(
> t, k ) before turning to the metamethods. I chose not to here, but that was
> essentially an arbitrary choice.

I do find it handy to be able to override an instance's method, sometimes only
temporarily, e.g. for getting a button's x-coordinate:

  function my_button_instance:GetX ()
     return (GetScreenWidth() - self:GetW()) / 2 -- Center the button
horizontally
  end

versus the GetX() belonging to the class itself.

Of course, while this use case favors doing the lookup first, it's
probably not a
very important one, as I doubt it's much more difficult to add the handling into
the mcall() itself.