[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enigma-devel] Lua API
From: |
Ronald Lamprecht |
Subject: |
Re: [Enigma-devel] Lua API |
Date: |
Sat, 10 Nov 2007 15:45:48 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (Windows/20070728) |
Hi,
Andreas Lochmann wrote:
[st-bolder]
concerning the global renamings:
Shall "st-bolder" be renamed to "st_boulder" to clear this old typo?
Personally I would vote for renaming it as the current name causes a lot
of typos and requests.
[Attributes in names]
And another proposal: For some libraries and other usages it would
be practical to incorporate attributes into the objectkind, e.g.:
"st_laser_n:on=true"
This pattern might even be used in group-selections:
activated_lasers = no["mylaser*:on=true"]
(or something similar to extract objects).
Libraries and complex levels may have a certain demand on complex
selcetion statements. Of course they can get the same results with 2 or
3 lines of code based on the basic API, too.
But I am not in favour of extending the selection string. It adds the
necessarity to parse and interprete Lua like syntax in the C++ engine.
Furtheron attributes that take string values would require a string
quoting within the selection string. And attributes that take object
references as values would refer to local variables - there is no
reasonable way to resolve a local Lua variable in the C++ engine.
All these problems can be solved by extending the method/function
arguments instead of the selection string (let Lua do the dirty work):
obj:is("st_laser", {on=true})
activated_lasers = no["mylaser*"]:select({on=true})
The second example is a new method "select" supported by any "group" to
generate a subgroup.
At least some more reserved characters besides "#", "?" and "*" for
names and object kinds would be a good idea for future changes.
It is likely that we define a set of valid characters on the final API
release. The listing above is just a list of characters, that we have to
exclude for sure.
Greets,
Ronald