Great to have another Rubyist around and appreciate your feedback!
when is a reserved word in ruby, so that exact syntax would not be possible.
Another method name could be possible, I can look into it. The current syntax supports arrays of items not just a single item so we might lose that without requiring them to be explicitly enclosed in an array. I can take a look at it, although I think I would add that as an optional syntax, not the only syntax. Are you proposing this just for items, or would you try to move the ‘every’ syntax into the when clause as well?
Additionally, if we have to repeat “when” and “received” everywhere is there benefit in that or is just noise hiding the true intent? I am not sure… I would be open to modeling it out if another method name can be found that doesn’t conflict.
This is all personal opinion and everyone’s will be different. I have it in my example conversion above but I will put it here as well:
@when("Item Office_Temperature changed")
@when("Item Thermostats_Upstairs_Temp changed")
@when("Item Office_Occupied changed")
@when("Item OfficeDoor changed")
changed Office_Temperature, Thermostats_Upstairs_Temp, Office_Occupied, OfficeDoor
To me, there is a lot of “noise” in the when the syntax that doesn’t provide a lot of value and is repeated without benefit. However, I can see both sides of it as it is close to what others are doing.
It would certainly be possible to also alias changed, updated etc to
when_updated which might be closer to the DSL syntax? That might be a good middle ground for those people who are drawn to the ‘when’ syntax. WDYT?
At the bare minimum a table needs to be created in the documentation that maps when syntax to the ruby syntax.
I don’t personally like the idea of using decorators or really string processing to create rules in Ruby. You lose syntax highlighting and make any of the meta-programming (that ruby is famous for) really hard. You would also lose compatibility with Rubocop and other tooling to format rules and enforce best practices automatically.
Great catch on the guards! I did look at using the condition syntax and would consider moving to that but the core doesn’t currently (that I know of) have the concept of
otherwise to run a block of code when the conditions aren’t met. Without
otherwise the guards become a lot less useful as a concept.
If the guard syntax is something people end up liking, then pushing otherwise or something else like it into the core (or at least notifying that the rule didn’t execute because of a condition) could be something added.