Re: Alternative (better?) __index implementation

["alex.mania@..." <alex.mania@...>]

I think I prefer Rici's solution, as it would ultimately allow respecting a
tables __call metamethod. Both solutions solve the getter/setter problem fine though.

On Wed Dec 12  6:11 , Mark Hamburg <mhamburg@adobe.com> sent:

>on 12/11/07 9:55 AM, Roberto Ierusalimschy at roberto@inf.puc-rio.br wrote:
>
>>> I've wanted a way to do this in Lightroom's class system. We optimize for
>>> the case where a class has no getters or setters, but most of the classes
>>> have them. The solution I'd been considering was to add an extra parameter
>>> to the index function giving the base table. I like Rici's solution,
>>> however.
>> 
>> Do you like or do you prefer Rici's solution? (If you prefer, why?)
>
>I'm not sure which I prefer. I would probably want to write some code
>against each approach.
>
>Extending the __index function avoids the legacy issue with Rici's approach
>of whether to support __index tables. On the other hand, it fairly
>specifically works for a one stage cache and potentially little else since
>you don't get any intermediate tables on the __index chain.
>
>Mark
>
>)