Re: Lua 5 and tags

[Mark Hamburg <mhamburg@...>]

The Lua 5 approach is somewhat less efficient than one might like. If
efficiency is a concern, there are a variety of things one can do:

* Rather than using strings to identify types, use light userdata. This
assumes that you have some permanent address to use for this purpose. This
will avoid some string manipulation when doing type-testing.

* If one counts on the garbage collector not moving things or at least on
lua_topointer being stable, you could use do a comparison on the result of
lua_topointer with the metatable. Note that this only works if your program
limits itself to creating only one Lua universe.

* I actually modified the Lua sources to allow a one-byte type tag on full
userdata. I use this to recognize some specific common cases where I can't
just do a metatable comparison. For example, I'm proxying to Objective-C
objects and I wanted a quick way to confirm that a full userdata was a proxy
for such an object before extracting the object pointer. I feel ever so
slightly dirty for having done this but it's a big win when crossing the
Lua/Objective-C boundary frequently (particularly if lua_lock is doing a
mutex lock).

One thing that would really help in the Lua specification would be a way to
bind methods to userdata such that they couldn't be pulled off and used
elsewhere -- i.e., they would be accessible as ud:method() but not as
ud.method. This would allow one to bypass type-tests in native method calls.
To go with this, one would also want something like:

    bindmethod( obj, method )

This would return a function to call method on obj.

Now, the Lua authors can rightfully ask whether profiling has really shown
these issues to be problems and I have to admit that most of my judgment
(after getting over the mutex overhead issues) stemmed from the observation
that for at least some native methods over the half the code was being spent
doing type-testing that could have been avoided rather than from actual
profiling.

Mark