at the pathname resolution stage (THEME:GetPath, ResolvePath),
not at loading. This means that pathnames to Lua files are actually
paths to Lua files, without any extra processing, and we always
load actual files (except for BGAnimation compatibility), not
directories.
(fixes Lua LoadActor() on a directory loading as a BGA and not
as Lua)
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.
Glenn Maynard