Imagine a conceptual leap with Grasshopper (pun intended) and related plug ins.
I’ve started to toy with grasshopper, and based on quite some experience designing industrial strength software systems using Model Driven Design (MDL, MDD or Eric Evan’s twist on model driven domains, called DDD) I almost immediately started to feel that something essential was missing in Grasshopper - the power to simply select a configured
Group of GH components and press um… let’s call it “Bake” or more precise, “Bake CustomComponent”.
You already got the idea.
All that has to be done to implement such a system is to save the “wiring diagram” of the components of the selected Group (let’s call this the “Orchestration” of components) and dump its definitions (connections) into a text file (not proprietary format for this). The name of the “baked” Group would serve as the name of the new CustomComponent (or a new name input by user in a dialog on Bake)
And from this “Baked” definition Grasshopper could then reconstruct the dumped diagram definition (but not showing the diagram details!) displaying only a GH CustomComponent (created on the fly) with the same name that the Group had when the original GH diagram first was “baked”.
The CustomComponent would also be automagically adorned with inPorts and outPorts representing the connections which the Group had extending outside itself when Baked.
The InPorts and OutPorts would be given default names, for example like this (priority wise):
- The user defined component name, if any, of the nearest connected component outside the group, and the GH compatible Type name.
- The GH Type name of the connected GH component (Example: Point)
If only a value was attached of defined, the inPorts could be named according to the user-named Slider (see §1 above, if any) including the Type, or only the Type (R,I,E,O) if only a value was set or attached.
Any internalized values and formulas/scripts would be automagically injected/initialized into the dynamically created CustomComponent by GH on recreating it from the dumped definition.
The definition file should have a syntax supported by BNF, preferably an existing imperative or declarative language, so as to allow for EXISTING alternate ways & tools for generating (i.e. code generation) such diagram definitions / Orchestrations, which then be loaded into GH/Rhino an executed there.
The definition files to be saved as plain text, optionally EXTERNAL to the 3dm file, as to allow for Version Control (Git, Mercurial etc) and DIFF tools and…
You get the idea. The definitions to be subject to the common tools that are already in use all over by software developers.
Two way/roundtrip engineering would then also be simple using the well known principles from the world of UML & Class Diagram tools (like Enterprise Architect, Rational (IBM) and others: https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools)
In this way Rhino/GH would potentially become one of the most powerful execution platforms for FBP-like programming, where a Grasshopper part-diagram, being built and tested and “Baked” could be added to a personal or shared library of powerful CustomComponents/concepts to be (re)used in other diagrams. Such a CustomComponent would actually represnet only one level of multiple, well, indefinitely nested CustomComponents / levels of components that at the lowest levels in most cases would be plain vanilla GH components.
In any case, it is in FBP-like solutions of great importance to separate the “Orchestration” from the processing units themselves (GH Components) since it simplifies parallel computing and more, and it is the Orchestration of components that represents the uniqueness of a User’s Design, an therefore the part that he would want to save and administrate separately with VCS and DIFF tools in a non-proprietary format.