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

[Steven Johnson <steve@...>]

> In the set ADT example above, storing "union" in the set would break
> the union method.  rawget(o, 'k') would determine behavior of both o.k
> and o:k.  The typical solution would then be for the object to instead
> store its private data in another table proxied through __index.

Ah, there is that. And wherever there have been public keys I have turned
toward just that sort of solution. :) And as with Penlight, another means
than __index for access.

Peaceful coexistence would be handy indeed.

> To bring up the method-operator analogy again--note also that we
> normally lack a handy way to override an individual instance's
> operators, though you could monkey patch the getmetatable(obj).__mcall
> table (affects all objects that use that metatable).

__mcall as a table might be messy, but with the function version you of
course get passed the object. Then overrides can be held in per-method
tables with objects as weak keys, and some means provided to set and
clear them.

Hmm, so changing course from my last post...

In my own case anyway, overrides are few and far enough between that this
wouldn't be so inconvenient. It then becomes possible to limit which ones are
even permitted; this would certainly give me some peace of mind about using
any old method call inside another public function or method. And some other
useful assumptions suddenly become valid.