Re: Guessing the expected result type from an __index function

[Jerome Vuarand <jerome.vuarand@...>]

2013/5/13 Jean-Luc Jumpertz <jean-luc@celedev.eu>:
> In this specific bridge context, my experience is that using the calling context of the index metamethod provide a better result from the user point-of-view, by enable him to choose freely which syntax to use.

If you want to provide to the user a mean to select property vs.
method based on syntax without modifying the interpreter, you can
still offer two distinct but valid Lua syntaxes, but choosing less
conventional ones. I can propose three that look reasonnable to me and
are easy to implement, but I'm sure many others are possible.

You could for example move all the properties access to a single
subfield of your objects. The methods would still be delivered by the
__index, and the properties by that intermediate "proxy" object. The
name of that object could be "_", short to type, no connotation, and
unlikely to clash with method names. This would give:

    local value = object._.property
    local result = object:method(arg1, arg2)

If you prefer keeping the __index for properties, you can use another
metamethod for the methods. For example you could use the __call
metamethod:

    local value = object.property
    local result = object 'method' (arg1, arg2)

That solution implies that the closure returned by __call keeps the
self parameter as an upvalue, and is thus instanciated per-object
(rather than per-class). The performance hit may be acceptable for
your use case, but to avoid it you can directly do the method call in
the __call:

    local value = object.property
    local result = object('method', arg1, arg2)

You asked for thoughts, I hope I didn't go too far off what you expected.