Re: Guessing the expected result type from an __index function

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

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

> You don't always know at index time how the returned value will be
> used. Consider for example:
> 
> local obj = get_one_of_your_objects()
> 
> local save = obj.save
> [...]
> With your hack, it's no longer possible to call the method in that way
> (which I admit is very unusual).

I am aware of this theoretical case. But it doesn't make much sense in general in an object-oriented code to extract a method function at some point and apply it later to an arbitrary object. And this is even more true when it concerns a bridge to an external compiled language. So I really don't consider this as an issue.

>  IMHO you should keep using the objc
> introspection mechanism you mention in the __index metamethod to
> distinguish between properties and methods, and provide a fallback
> mechanism for when it's not properly registered by the third party
> object author

I started with this idea but unfortunately this way of doing tends to be really dedious when you write Lua code using this type of bridge. Trying to guess whether you shall use a field-type or a method-type syntax causes lots of errors like "trying to call a userdata as a function" or "can not dereference a field from a function".
And the issue is made worse due to the big size and long history of the target library, which is actually the full iOS / Mac OS SDK.

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.

Le 13 mai 2013 à 09:58, steve donovan <steve.j.donovan@gmail.com> a écrit :

> On Mon, May 13, 2013 at 9:38 AM, Jerome Vuarand <jerome.vuarand@gmail.com> wrote:
> I don't know ObjectiveC, but from your description there doesn't seem
> to be any perfect solution.
> 
> Yes, in LuaJava the strategy is first to see if the symbol is a field or property, and only if that fails, then to try for a method. This works, although was rather expensive in the context of Android and now I'm caching per-object whether something is a known field. Which cuts down significantly the amount of garbage generated by reflection and (NB) by 'field-not-found' exceptions.

Agree. The per-object caching is necessary and I am also doing one (per-class) in the Objective C bridge. And, as the property lookup is really expensive as well for objective C, another advantage of the calling context detection is to limit the property lookup to the rather cases where the property getter method doesn't have the same name as the property.