Re: enum/bitops patch

[Asko Kauppi <askok@...>]

Got it working now.  (see - no smiley.. :!)

Diff for Lua 5.1.1 (some 650 lines if it was cleansed):
  svn cat svn://slugak.dyndns.org/public/lua-bitwise/lua-5.1.1-enum- 
patch.diff

The Whole Lot (try "make test"):
  svn co svn://slugak.dyndns.org/public/lua-bitwise

The approach this patch takes -- and I'm only testing the approaches  
-- is to be all Lua-internal, except for "enum.new()" that is offered  
for Lua script side creation of these 'enum's.

Enum's are basically unsigned 32-bit values, with family info. You  
cannot do operations between them and numbers (numbers are _not_  
bitfields), and you cannot do inter-family operations either. This  
protects one from using the wrong kind of 0x10 in an API call. Should  
be a good thing.

However..

<<README>>
The patch works, but...

mutability of enums (val[9]=1) needs to be turned off.  And if it is,  
the same can be
achieved with a dynamically loaded module, as well.

The question becomes (performance issues aside) whether having a  
standard 'built-in'
solution for enum/bitfield handling within Lua itself is so  
preferable that it's worth
the added 700+ lines (including comments) that are required. Maybe not.

On the other hand, enums do need both Lua/C API and Lua side support  
(= C modules should
be able to bind bitfield types and values effortlessly, and in a  
standard way). For this
reason, a certain Lua C API add-on will anyways be needed, and if  
such an add-on is not
delivered with Lua, chances are there will be incompatible approaches  
even in the future.

Survey's done, prototype's working, the rest is ... politics.

- Asko Kauppi
  1-Oct-06
<<

I'll also place an entry to the Wiki PowerPatches page, just in case.

-asko


askok@dnainternet.net kirjoitti 28.9.2006 kello 9.11:

> I've been developing a suggestion to the enum/bitwise operations  
> issue, discussed extensively on the List lately.  Seems like the  
> best way to cut that thread?
>
> Now, I'm in a dead end position with 2 places in the code causing  
> headaches.  Would like to pleed for help, anyone with under the  
> hood Lua core understanding, would you please do the rest?  :)
>
> How-to:
>
>   svn co svn://slugak.dyndns.org/public/rocks/bitwise
>   cd bitwise
>   make test
>
> Mod top level Makefile if you're not running OS X (one liner).
>
> What the patch does:
>
> - enum.new( value_int [,family_str] )  provides a means for Lua  
> code to create 'enums', which belong to a family. If you leave the  
> family part out, they are "anonymous" (which in a way is just a  
> family itself, too)
>
> - existing operators offer bitwise manipulation to the enums,  
> _within_ their family.  See test.lua for samples.
>   New operators can also be used, but I don't personally see that  
> vital.
>
> - inter-family operations are not allowed (that's the whole purpose!)
>
> - C API has means to generate enums from C modules
>
> typedef struct _lua_enum_tag *lua_EnumTag;
> LUA_API lua_EnumTag lua_newenumtag (lua_State *L, const char *family);
> LUA_API lua_EnumTag lua_enumtag (lua_State *L, int idx);
> LUA_API lua_Enum lua_toenum (lua_State *L, int idx, lua_EnumTag tag);
> LUA_API void lua_pushenum (lua_State *L, lua_Enum v, lua_EnumTag tag);
> LUA_API const char *lua_enumtagname (lua_State *L, lua_EnumTag tag);
>
>
> Warning:   I may be moving the folder to another URL soon, since  
> it's not a 'rock' after all.   bitwise.[lua|c] files are not  
> needed; they're leftovers of when I thought this could be done as a  
> pure module.  There's limitations, if it's done that way.
>
> thanks,
> -asko
>
> ps. thanks to the recent 4x listing in top-smileys, I'm currently  
> cutting my emotions back heavily.   I am... ;)