Re: New metamethod for method lookup

[TNHarris <telliamed@...>]

On Sun, 15 Nov 2009 11:59:20 +0200
steve donovan <steve.j.donovan@gmail.com> wrote:
> 
> Basically, there is a need to separate method lookup from field
> lookup, but in such a way that the old method is always available.
> 
> Here is the problem case: say you wish to wrap a set as an object. Say
> also that you want s[val] to _reliably and always_ indicate the
> presence of val in the set s.  Currently, this cannot be be done.  If
> our set has an intersection() method, then s['intersection'] will
> always be a false positive, because we look up 'intersection' in the
> set's metatable if lookup fails.  So we have to write this operation
> as a method call, say s:get(val) or s:exists(val) that uses rawget
> internally, which isn't so pretty or intuitive.
> 

What about dot syntax?. I'd expect set.intersection to not be the same
thing as set['intersection'] in the object you describe. There's too
many surprises if colon and dot did different things. And this doesn't
have to be limited to functions, so calling it "method indexing" would
be inexact.

So the metafield could be __property, __field, __objindex, __metaindex.
It would be used the same way as __index for dot and colon syntax. The
API would also need new functions.

How would you add new fields? object.field = function() end couldn't use
__newindex. 

This proposal is also needed to create userdata objects that have
methods and must be subscriptable.

-- tom
telliamed@whoopdedo.org