[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Alternative (better?) __index implementation
- From: Rici Lake <lua@...>
- Date: Sat, 1 Dec 2007 16:55:38 -0500
On 1-Dec-07, at 5:53 AM, firstname.lastname@example.org wrote:
I can see this would be a problem with particular, but still rare
trying to memoize a tables __index function would break, as you say.
trying to use an already memoized function as a tables __index would
It may be rare in your code. It's common in mine. Styles vary, of
Again, not so sure I agree with putting redundant in demeaning quotes
It's no more demeaning than the use of the word "rare", surely? But it
actually just a quote. I'd say the function call is not so much
optimizable, much like the extra function call in a curried closure, or
indeed any function call which could be inlined. That is, it is
a function call but a cleverer compiler (or runtime) might well be able
optimize it away.
What in your opinion
would be the best way to handle __newindex regarding proxys?
__newindex should certainly ignore __proxy. It would be possible to
a __newproxy as well, although I don't know how much it would be used.
advantage would be the separation of call from (set)index, as I
It's very common to want __index to retrieve from a backup table but not
want __newindex to write into it. In fact, having __newindex respect
__proxy would make __proxy unusable for the common case of inheritance.
And it is a shame that not providing the compatibility would break so
apps. Maybe make it #definable, but defined in by default; similar to
a few things
in the current Lua 5.1 implementation.
Yes. The compatibility implementation I'd recommend would be to try the
first, and back up to the table index only if (1) there was no __proxy
and (2) the self object is not callable. However, this is not 100%