lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 1-Dec-07, at 5:53 AM, 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

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.