pyiron / pyiron_workflow

Graph-and-node based workflows
BSD 3-Clause "New" or "Revised" License
10 stars 1 forks source link

Decompose `Node` #243

Closed liamhuber closed 3 months ago

liamhuber commented 3 months ago

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, and h5io -- 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 with

So 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 of Node.label), but this proliferated trouble with h5io due to all the recursive relationships. So instead I'm opting for mutliple-inheritance mixin-compositions.

My current attack plan is:

liamhuber commented 3 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.