Re: __method metamethod

[Coda Highland <chighland@...>]

On Mon, Jul 29, 2013 at 11:51 AM, Jay Carlson <nop@nop.com> wrote:
> On Jul 28, 2013, at 9:50 PM, Coda Highland wrote:
>
>> On Sun, Jul 28, 2013 at 4:42 PM, Jay Carlson <nop@nop.com> wrote:
>>> On Jul 27, 2013, at 2:47 PM, Mark Hamburg wrote:
>>>
>>>> I used to want the colon operator raised to first-class status where it could then have a metamethod, but I never found a formulation that really seemed useful. (Someone can go find my old postings on the topic and point out how much I forget...)
>>>
>>> I have a very bad feeling about creating *half* an extra namespace. We might as well make it an lvalue too: __setmethod.
>>
>> I still think that __index is sufficient here; I have a very bad
>> feeling about having a.b and a:b reference different concepts.
>
> Oh, sure. The next question is how a:b is related to a["b"], and I think the answers get worse and worse until you arrive at a two-namespace Python-object-like table. But reification of *methods* needs some clear reasoning. It's much simpler to look at Mark's (clipped) suggestions of a bare "o:m" as syntactic sugar for
>
> function (obj,method)
>   return function (...)
>     return obj[method](obj, ...)
>   end
> end(o,stringify(m))

I had made the same description several days ago, except I had granted
the possibility of having a "bound function" subtype that isn't a full
closure, which would enable equality checks (do these two variables
refer to the same function bound to the same object? yes? okay,
they're equal).

/s/ Adam