The use of members named "value" and "discriminator" in a union are problematic because of the existence of properties on the IdlUnion class with these names. (The error message are quite confusing.) For example, this:
union U switch (boolean) {
case TRUE: string value;
};
would result in a union where you could not set the value. You might be able to get it, more or less by accident. If instead of "value" the member would be named "discriminator", it'd be even worse.
The IDL spec has a mechanism for dealing with these problems: the use of a leading underscore as an keyword escape mechanism, both on the IDL and the language binding. The Python already used this for keywords, now it also uses it for these two identifiers in unions. Thus, the above now maps to:
class U(idl.IdlUnion, discriminator=bool, discriminator_is_key=False, typename="U"):
_value: types.case[[True], str]
annotate.member_name("_value","value")
Trying to define a union with these members (without the leading underscore) now raises an exception. The underscore is not in the TypeObjects and also stripped in the IDL output by cyclonedds typeof.
Fixes #245 (@FirebarSim, perhaps you can verify this claim?)
The use of members named "value" and "discriminator" in a union are problematic because of the existence of properties on the IdlUnion class with these names. (The error message are quite confusing.) For example, this:
would result in a union where you could not set the value. You might be able to get it, more or less by accident. If instead of "value" the member would be named "discriminator", it'd be even worse.
The IDL spec has a mechanism for dealing with these problems: the use of a leading underscore as an keyword escape mechanism, both on the IDL and the language binding. The Python already used this for keywords, now it also uses it for these two identifiers in unions. Thus, the above now maps to:
Trying to define a union with these members (without the leading underscore) now raises an exception. The underscore is not in the TypeObjects and also stripped in the IDL output by
cyclonedds typeof
.Fixes #245 (@FirebarSim, perhaps you can verify this claim?)