[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: On lua5 and embedding
- From: "Bilyk, Alex" <ABilyk@...>
- Date: Tue, 28 Jan 2003 18:39:56 -0800
Well, those developing the language have pretty heavy load on the their hands when it comes to satisfying every Lua user out there. The authors of the language probably have their own agenda on the future of Lua in addition to being from academia where the real world problems are looked upon through a peculiar rainbow glasses at least part-time. On the other hand, it is in people's nature to exhibit certain amount of inertia when it comes to changes. Whatever the change, there will be someone who is not satisfied with it and inevitably bitches about it. So, I usually tend to move on and deal with it rather than arguing about things to death. I am sure you have similar attitude in your work. If one day I found that this meta-table performance issue is a showstopper, I would just implement the cache myself. Looks like about a day or two of work for someone who doesn't know all ins and outs.
From: jimmyp_gr <email@example.com> [mailto:firstname.lastname@example.org]
Sent: Tuesday, January 28, 2003 5:41 PM
To: Multiple recipients of list
Subject: Re: On lua5 and embedding
> Yes, the caching is done. But... To my taste it is done for the
wrong case. Namely, culling non-existent meta-methods for some
selected events is the fastest case (just a flag check). But access to
any existing meta-method is a Lua-table lookup. I am not saying the
ok then.Why not implement the __get and __set metamethods and let the
user set them if he/she wants to pay the price.They're existence
wouldn't bother anyone.And besides the actual metamethod function
pointers can be cached as well(not just existence flags) just get a
pointer to the value of the key "__get".The value may change but its
place in the table should remain fixed.
In any case a solution should be worked out.This is seriously damaging
lua functionality.I'd be interested in a response from someone from
the developer team on this...