converting the metric to a string and then back into Lua, and
works with any type; with "Class::Metric=math.sin",
THEME:GetMetric("Class","Metric") will return the function sin().
just sticks the result in AutoPtrCopyOnWrite. apActorCommands might be
eliminated; it's reference counting a garbage collected object. (It
used to be more useful, when we stored actual command lists; now I'm
not sure whether it is. Need to benchmark LuaRef copying to see.)
So, we shouldn't be treating them differently, but we are:
GetMetric(apActorCommands) parses actor commands, and GetMetric(LuaRef)
does not. I don't like that distinction; actor commands can be passed
around as a LuaReference, and other references can be put in
apActorCommands. "Whether it's in a smart pointer" is a strange
way to decide which overload to use.
Also, we should have a consistent way to know whether a metric is to
be parsed as a command or as a Lua expression, based on the data
itself and not the code being used to read it. Let's use the name:
all commands end with "Command". We already depend on this elsewhere,
in ActorUtil::LoadAllCommandsFromName.
Note that "actor commands" are not specific to the Actor system,
other than a few compatibility hacks; they're just a shorthand
for writing Lua functions.
Lua expressions, and commands simply allow a shorthand that generates
valid Lua expressions. Make strings Lua expressions.
This essentially reverses strings; rather than:
Metric1=Text
Metric2=@Text()
specify:
Metric1="Text"
Metric2=Text()
This means that every metric (except Fallback, currently) can be
treated as a Lua expression, except for Command metrics that just
need a bit of preprocessing.
to Lua when the singleton is constructed, and not in the
binding class. The binding just adds the class bindings
(the same as for a non-singleton class). This way, the
binding is available to Lua as soon as the class is constructed.
serializing data and tables while reinstantiating Lua. That's
ugly, and can't serialize some things (eg. functions).
Instead, when changing themes, shut down the high-level objects
and unregister as much as we can from Lua, change the theme,
then reregister things. This doesn't clean the slate as much;
globals won't be erased, etc.
A better way would be to clear everything that uses Lua
(delete singletons), then reload it all. Singleton creation is
a bit of a mess currently so that would break a lot, and we
don't want to reload songs.
Steve Checkoway