Re: Alternative (better?) __index implementation

[Rici Lake <lua@...>]

On 1-Dec-07, at 5:53 AM, alex.mania@iinet.net.au wrote:

> I can see this would be a problem with particular, but still rare 
> contexts. Eg
> trying to memoize a tables __index function would break, as you say. 
> Similarly
> trying to use an already memoized function as a tables __index would 
> break.

It may be rare in your code. It's common in mine. Styles vary, of 
course.

> Again, not so sure I agree with putting redundant in demeaning quotes 
> there ;)

It's no more demeaning than the use of the word "rare", surely? But it 
was
actually just a quote. I'd say the function call is not so much 
redundant as
optimizable, much like the extra function call in a curried closure, or
indeed any function call which could be inlined. That is, it is 
semantically
a function call but a cleverer compiler (or runtime) might well be able 
to
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 
define
a __newproxy as well, although I don't know how much it would be used. 
The
advantage would be the separation of call from (set)index, as I 
mentioned
earlier.

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 
> many existing
> 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 
call
first, and back up to the table index only if (1) there was no __proxy 
method,
and (2) the self object is not callable. However, this is not 100% 
compatible.