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.
Glenn Maynard