Re: Guessing the expected result type from an __index function

[Jean-Luc Jumpertz <jean-luc@...>]

Le 13 mai 2013 à 15:52, Jerome Vuarand <jerome.vuarand@gmail.com> a écrit :

> 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)

Thanks for theses syntax suggestions. They have the advantage of addressing the problem without changing the Lua VM as it is today.
However I wouldn't feel comfortable proposing such syntax to my users as it would brings extra complexity to the Lua language (or at least to the way to use Lua with my library) and the users would probably just consider it a weird way of accessing two already existing basic features of the language: fields and methods. 

As every technical design decision is a matter of finding the best (or least bad) compromise for a given problem, my priority for this one was to keep things as simple as possible for the user, hence the choice of allowing Lua standard field and method syntaxes for accessing properties, even if it requires minor additions to the Lua code itself. 

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


Not at All :-)

Actually the intent of this post was:
- to check if other members of the Lua community ran into the same problem before and how they solved it.
- to get feedback about my proposed way of getting the method / non methods context of an index metamethod call, based on the current op-code
- to keep a track of this implementation in case it could be of some help for others in the future
  (ok, I know, for this one github is a better place, but is really necessary to create a repository for 15 lines of so simple code? ;)

Jean-Luc