If we want to use three-valued flags we could use EBooleanObject (which will be mapped to Boolean objects). You are right: this way we can ensure backward compatibility. Neat!
Regarding the graphical editor: I also don't have a good idea yet. But I think the most important part is that we have it in the model and support it in the interpreter. I was planning to add "in" and "out" keywords to the parameter list, but that works only for two-valued flags :(
in order to not break existing transformations, we could use
three-valued Enum attributes instead of boolean flags, with the
values "true", "false" and "neutral". "neutral" would be the
default value.
The issue I see is how to support this in the graphical editor. We
really haven't found a nice concept yet. One idea is to assign
keywords to the parameter names in the comma-seperated list, which
effectively bloats up the rules in width. Another idea is to use
several compartments for the different parameter types, which
bloats up in the rules in height.
Regards,
Daniel
Am 31.10.2014 08:58, schrieb Christian Krause:
Hi,
Since this topic already came up in the discussion,
here is one proposal for a refined parameter concept:
The Parameter class gets two boolean flags: "input"
and "output". If the input flag is set the parameter value must
be provided by the user (if not the engine throws an exception).
If the input flag is not set it will be matched by the engine.
The engine would similarly provide only output Parameters back
to the application. Parameters which are neither input nor
output are internal variables. And of course it is also possible
to have in+out params.
The only worry I have is that when we introduce this
change we will break existing transformations.