[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Alternative (better?) __index implementation
- From: "alex.mania@..." <alex.mania@...>
- Date: Wed, 12 Dec 2007 16:22:48 +0900
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 <firstname.lastname@example.org> sent:
>on 12/11/07 9:55 AM, Roberto Ierusalimschy at email@example.com 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,
>> 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.