In addition to @RIL’s example, here’s what I imagine this is useful for:
- You can split up large files into consecutive smaller files. Making each file more readable, more re-usable, and more debuggable.
- You can store various states of data to work on, and switch between them either through the GH UI or using the file viewer in your OS. You might just want different states, or you may want heavily reduced versions of the same states so that you can work on a small part of the logic and only switch to the full-blown-it-takes-20-minutes-to-compute finished model at the very end.
- It allows you to work together with other team members more easily. Person A is in charge of facade shapes, person B is doing the rationalisation, person C is populating facade elements, person D is all about creating shop drawings, machining instructions and material bills, each working in their own gh files but sharing data.
There are other reasons, but these I think are the most important.
Eventually for a proper implementation I’m imagining that both cluster hooks and these data exchanges are the same sort of object. It has to work both to and from separate *ghdata files, and also directly into other *.gh files, and of course across cluster boundaries.