calculated_item helper #131
Conversation
| # @return [Core::Types::State] | ||
| # | ||
| # If a Proc is given, {Rules::Terse.calculated_item calculated_item} | ||
| # will be used to keep the item's state up to date. |
There was a problem hiding this comment.
An example demonstrating how to use this would be great. It could be a part of the main Builder module's description above, I just can't add a comment there.
|
refs boc-tothefuture#459 |
| rule name, id: id, script: script, binding: block.binding do | ||
| changed(*items) | ||
| run do | ||
| item.ensure.update(yield) |
There was a problem hiding this comment.
Should we add a state check here, to ensure that none of the captured items are undef?
There was a problem hiding this comment.
the problem is it’s not so easy. I have to run the block essentially as an on_load in order to identify the items. but I can’t check their state is not nil until I know what items I’m looking at
I can’t even catch NoMethodError, because that will interrupt execution of the block, so I won’t know what other items were accessed
I could, only within the context of a capture_items block, instead of returning nil return a special object that delegates to nil, but swallows any NoMethodErrors. but that sounds super error-prone
I think a better option would be to allow explicitly specifying the dependencies, and then if you do that, have an option for require_state: true
WDYT?
There was a problem hiding this comment.
I'm going to noodle on this a bit. even if you make the user have their block be written to be safe in the face of UnDefType, it would likely return nil, and it might be the case that when that happens they want to not update the item, instead of updating it to NULL. but automatic item capture is like 90% of the appeal of this feature
There was a problem hiding this comment.
waiting for the result of your noodling
| number_item Furnace_DeltaTemp | ||
| number_item FurnaceSupplyAir_Temp, state: 80 | ||
| number_item FurnaceReturnAir_Temp, state: 70 | ||
| end |
There was a problem hiding this comment.
Remove the initial state here, and test the rule when the items involved are UNDEF/NULL.
|
Would it work with something like this? Note that not all items involved are looked up through one execution path. calculated_item(ItemTotal) do
if Item5.state == 5
Item1.state + Item2.state
else
Item2.state + Item3.state
end
end |
|
No, it wouldn't, at least not as currently implemented. I've been thinking of bringing in an actual Ruby parser, instead of running the block. But that likely wouldn't handle item references from nested method calls. So then I'm back to explicitly naming dependencies, and then deciding which (or multiple) auto-detection strategies to allow. |
No description provided.