[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: Lightweight Lua Enumerations
From:       Asko Kauppi <askok () dnainternet ! net>
Date:       2007-06-28 17:28:17
Message-ID: F8E46D96-432E-43F1-8866-B7D839810E91 () dnainternet ! net
[Download RAW message or body]


I've been working with Lua enums lately, too. Or rather, Lua/C enums,  
since I believe a direct connection to the C side is often essential  
in this question. Most enumerations originally come from C libraries,  
and thus binding them right through is safer and less work, than  
duplicating the values in Lua.

Light userdata would otherwise be perfect, but they don't support  
metatables.

My solution is real userdata, with an ".etag" string in the  
metatable, giving away the enumeration family. This way, code can be  
made enumeration family aware (cross-family usage caught at runtime).

Final problem, which remained, was table access. Having two userdata  
with same "value" does not grant uniqueness when used as table keys.  
This is important for UI callback tables, for example. The way I had  
to solve it (not ideal) is keeping a list of existing values, and if  
a new, say, 0x8000 is pushed, that existing cache is checked first  
and a value from there used instead. This grants uniqueness as table  
keys, but may consume quite a bit of memory if there are many  
individual enum values. Good for me, though.

A solution from Lua that would grant "all of the best" would be a  
middle layer, "semi-light" userdata, which would work as pointers,  
but allow for metamethods. That would take the need for the nasty  
already existing values lookup away.

-asko


[prev in list] [next in list] [prev in thread] [next in thread]