Closed liamhuber closed 7 months ago
Ok, I'm quite happy with this. I'm quite certain that there is room for improvement, and it's always possible that one goes too far decomposing things into too small of pieces, but overall this feels better. IMO the proof is in the pudding with how easy it was to now give all nodes "single value" power in #255. Critically, pyiron_workflow.node
went from an unwieldy 1302 lines down to 729 -- a 46% reduction. There will be more to do in the future, but I feel this is a reasonable stopping point to go harvest some fruit from the improved infrastructure and get feature implementation done.
The
Node
class has gotten a bit unwieldy. I feel that the way I added storage, especially on top of two backends that are non-optimal (tinybase
being incomplete, andh5io
-- most of all -- not accommodating rercursive attributes) has resulted in some technical debt.This became particularly evident in #240 when I tried to merge storage into Joerg's branch. I knew already that
Node.iter
didn't play well with the graph paradigm, but with storage present simply creating new copies of the same node withSo what I'd like to do is break apart
Node
into some different pieces to separate out the concerns and break responsibilities into smaller pieces. I had initially tried a purely component-based composition approach (e.g.Node.semantics.label
instead ofNode.label
), but this proliferated trouble withh5io
due to all the recursive relationships. So instead I'm opting for mutliple-inheritance mixin-compositions.My current attack plan is:
Semantics
to handle labels, uniqueness, child/parent relationships, etc. (#244)Runnable
(#246)HasIO
to (#252)HasIO
where there is only one output data channel, so we can close #155 and reduce the number of user-facing classes (justFunction
andMacro
, no moreSingleValue
) at the same time. (#255, #257)