[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Enigma-devel] 2 types of world::Object
From: |
Tacvek |
Subject: |
[Enigma-devel] 2 types of world::Object |
Date: |
Wed, 22 Mar 2006 15:27:45 -0500 |
My patch to port r99 to Lua 5.1 is nearly ready, and some of my previous
comments about the patch are incorrect.
When I post the actual patch I will include all notes about what is and is
not correct at that point.
Anyway, I have run into a bit of a snag.
Enigma appears to expose two different kinds of world::Object to Lua.
One is the type that things in Lua.cc deal with. The userdata of this type
is tagged. A generic object of this type can be created in Lua using
enigma.MakeObject("name").
A few of the other functions in Lua.cc can create this type of object. All
of the functions will happily deal with it.
The other type of world::Object is the one dealt with the functions made
accessable via tolua. The userdta of this type lacks tags. A generic object
of this type can be created in lua using world.MakeObject. While most
fuctions will accept objects of this type, functions in Lua.cc will not.
The easiest way to proccede is to eliminate the first type of world::object.
The downside of this is that it would not be possible to verify if a
userdata passed to a function is really a world::Object. However, it turns
out that only the functions in lua.cc are doing this anyway. The other
functions don't check type.
If the typecheking on those functions in lua.cc is too important to scrap,
then it looks to me like some major arcitectural changes would be required
to support
versions of Lua >4. Otherwise, I can drop the type checking, and convert the
remaining Lua.cc functions that are callable from lua into tolua functions,
and move them into an appoprate source file.
(It looks to be just plain luck that the way the code worked out, no objects
of the none-tagged variety ever need to be passed to a lua.cc function.)
- [Enigma-devel] 2 types of world::Object,
Tacvek <=