[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Alternative (better?) __index implementation
- From: "alex.mania@..." <alex.mania@...>
- Date: Sun, 02 Dec 2007 12:00:02 +0900
>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
>> there ;)
>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.
That's definitely something I'd like to see in a lua compiler (or more probably,
jit-er). Would be quite a challenge to inline metamethods though; without
massive amounts of static analysis you would have to look up the metamethod every
time to ensure that it's still the same as the inlined version.
Sorry about the use of the word rare ^^
>> 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
That was my thoughts. In fact, newproxy might be so infrequently used to leave
it up to the user to use workarounds via newindex functions. Dunno =)
So in summary, you'd recommend: (Please correct me if I'm wrong)
Get table, before returning nil to (recursively) call self with the __proxy
table, if it exists. If __proxy also yields nil, to attempt calling the __index
metamethod; be it a function or a table with a __call metamethod. For
compatibility would be best to attempt to index the __index metamethod if it's a
Set table, before setting a previously nil key would ignore the __proxy
metamethod/table and simple call the __newindex if it exists.