Sometimes development of a features takes very long and you do not want to branch out from the main branch for so long. One possible solution for this are feature toggles. You enable or disable a feature depending on a certain condition (for example the current user group is the beta tester or production group).
Depending on this boolean, you branch your programs behavior: Production users get the old implementation, beta testers the new incomplete version.
Feature toggles in Langium
Old syntax
Toggling language features is actually already possible, but based on constants (that are TRUE or FALSE).
Identifier<QuotedStringAsId>: IDENTIFIER | <QuotedStringAsId> STRING;
//use it later with constant
RuleX: 'blubb' name=Identifier<false>;
RuleY: 'blip' name=Identifier<true>;
terminal IDENTIFIER: /[a-zA-Z_][a-zA-Z_0-9]*/;
terminal STRING: /“[^"]*"/;
You cannot give in a value from outside currently, but it should be a low hanging fruit, since the conditional rules are already part of Langium.
New syntax
What I would like to propose is a new syntax for feature toggles inside the Langium syntax:
//flag name = default value (default should be false)
feature QuotedStringAsId = false;
Identifier: IDENTIFIER | <QuotedStringAsId> STRING;
...
The Langium generator will additionally add an object of feature toggles:
The toggles can be dynamically set during creation of the services object. Making them accessible through the services, each child service can access the actual values and react properly if needed.
Original problem
This idea came up from a langium-sql issue. LangiumSQL tries to be a SQL solution for multiple dialects. Dialects differ for identifiers:
MySQL likes double-quoted strings as identifiers. For other dialects it can be a string literal, no identifier. A feature toggle was not the original idea, but it would be possible to implement this uncertainty with feature toggles and decide on a dialect when initializing Langium's services object.
In detail by Martin Fowler: https://martinfowler.com/articles/feature-toggles.html
Example
Sometimes development of a features takes very long and you do not want to branch out from the main branch for so long. One possible solution for this are feature toggles. You enable or disable a feature depending on a certain condition (for example the current user group is the beta tester or production group).
Depending on this boolean, you branch your programs behavior: Production users get the old implementation, beta testers the new incomplete version.
Feature toggles in Langium
Old syntax
Toggling language features is actually already possible, but based on constants (that are TRUE or FALSE).
You cannot give in a value from outside currently, but it should be a low hanging fruit, since the conditional rules are already part of Langium.
New syntax
What I would like to propose is a new syntax for feature toggles inside the Langium syntax:
The Langium generator will additionally add an object of feature toggles:
The toggles can be dynamically set during creation of the services object. Making them accessible through the services, each child service can access the actual values and react properly if needed.
Original problem
This idea came up from a langium-sql issue. LangiumSQL tries to be a SQL solution for multiple dialects. Dialects differ for identifiers: MySQL likes double-quoted strings as identifiers. For other dialects it can be a string literal, no identifier. A feature toggle was not the original idea, but it would be possible to implement this uncertainty with feature toggles and decide on a dialect when initializing Langium's services object.