Thanks @AndersDeleuran,
This is helpful a lot.
However the issue still exists. You don’t use additional components in GH to instantiate datatrees this should be included in the virtual components.
That’s true, however I’d recommend against mixing apples and oranges here (i.e. imperative/textual programming with IronPython/C#/VB and declarative/DAG-based programming with Grasshopper) and to mainly/only use the virtual components for calling stuff that isn’t exposed in RhinoCommon or rhinoscriptsyntax (say the Voronoi functions). Mixing paradigms like this will more than likely lead to unnecessary complexity and confusion, both as the programmer (try debugging those calls!) and anyone reading the program.
This statement renders virtual components useless.
They are beautiful addition for novice programmers like myself. Help you to not deal with all that stuff and actually program just what you need. Allowing you also to combining multiple components into a single one. This way you can create something otherwise not possible (e.g. self updating cluster)
Well no, as you can call Grasshopper exclusive stuff (even from third party plugins) that isn’t exposed .NET-style in RhinoCommon and the Grasshopper API, or Python-style in rhinoscriptsyntax, as I said.
Beautiful, but misleading, ultimately leading to said unnecessary complexity and confusion.
You’re essentially Grasshoppering/wiring within GHPython with the virtual components, which (IMO/experience with students) will harm more than help in terms of learning (imperative/textual) programming. But you do you 