>
> [Unions]
> > That is probably the only C keyword that I have never used, so I know its
> name ;-)
>
> Let me repeat the code I presented for the Value system:
>
> struct Value {
> union {
> double real;
> int integer;
> ...
This somehow reminds me to the systems of "properties" most of the
(German) MUDs use: There you have "objects" (like rooms, players,
non-player-characters, weapons etc.) and each object has a set of
porperties (like description, value, weight etc.) The set of properties
is *not* fixed (because most of them do not make sense in every
kind of object - rooms do not have a value since you can't take and
sell them e.g.).
The property system is realized as a mapping string->value, string
being the name of the property (like "weight"), and value its value
(of course).
The system is fast enough to handle 200 players in 10000 rooms with
another 10-30000 objects although the code to set and query
properties is executed by an *interpreter* an not compiled!
Every coder can add properties at every time. In our setting this would
mean that you can have some high-level-description of e.g. some inset
that uses some variable used by this kind of insets only (some
counter...). This variable does not have to be built-in into the lyx
binary!
If there is some interest in this property system I could try to find
some documentation, but I think it's rather easy to implement...
Andre'
> bool boolean;
> string str;
> wstring wstr;
> LString lstr;
> vector<Value> list;
> vector<Value> tuple;
> vector<pair<string, Value> > record;
> } value;
>
> enum {
> Real, Integer, Boolean, Str, WStr, LStr, List, Tuple, Record
> } tag;
>
> Value & operator+(Value const & v);
> Value & operator-(Value const & v);
> Value & operator*(Value const & v);
> Value & operator/(Value const & v);
> [etc]
> };
>
> This Value is a means to emulate polymorphic values -- values with flexible
> types. With this structure, we can support booleans, integers, strings in
> various shapes as the fundamental values. On top of this, we can represent any
> derived datastructure using lists, tuples (anonymous records), and records.
>
> These Values then have a bunch of operations defined, like addition,
> substraction and what not.
>
> So, in the Paragraph structure, I propose that we simply have this:
>
> struct Paragraph {
>
> map<string, Value> settings;
> };
>
> So the "settings" map is our state of the paragraph. Inside this, we have
> defined all the values that are different from the default settings.
>
> This way, we should be able to preserve memory, and still be very flexible.
> For instance, it's no problem to introduce new properties in a layout file,
> because no variables are hardcoded.
>
> Greets,
>
> Asger
>
>
--
Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik
[EMAIL PROTECTED] ... +49 3727 58 1381
