Re: [Enigma-devel] Lua API

[Ronald Lamprecht]

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