Most Challenging Components to create during grasshoppers' development?

Hi David, I'm curious if you might be able to comment on what was the most difficult component to create during your development of the grasshopper project we all know and love today? Likewise, do you have a favorite component or set of components that you're particularly fond of? Just curious. Thanks for all that you do! I can't imagine how different my work and architecture would be different without your continued involvement in this project over the many years it has been in development.
Tyler

Replies to This Discussion

Permalink Reply by David Rutten on March 29, 2016 at 12:12pm

Hi Paul,

sorry, but GH2 is a total rewrite which means pretty much everything that could be broken in terms of API continuity, will be broken. Here are just a few of the changes that would make it impossible to provide any sort of backwards compatibility:

Deal with data types directly instead of IGH_Goo wrappers.
Deal with more type-safety in getting and setting data to inputs/outputs.
Inform GH about any multi-threading strengths and weaknesses they may have.
Provide multi-resolution, vector, or algorithmic icons.
Deal with a different naming scheme for tab/panel positioning.
Deal with a different set of standard parameters.
Deal with a different set of events.
Deal with a different approach to solver iterations.
Deal with an immutable approach to file IO.
Switch to a wholly different previewing scheme
...
...

Perhaps, on a purely theoretical level, components that interact with GH classes as little as possible may be automatically converted using some sort of Mono.Cecil code-swap scheme, but I shiver just thinking of the amount of untraceable bugs that will cause.

Permalink Reply by Paul N Jeffries on March 29, 2016 at 1:55pm

Thanks David,

No worries - that's pretty much what I was expecting and those all seem like great improvements. The reason that I'm asking is that I'm just about to embark on writing a new Grasshopper library and would ideally like to set it up in such a way that it won't be too difficult to make compatible with GH2 as well when the time comes. I'm already arranging it such that I have a component base class that wraps my own 'action' interface and populates inputs and outputs automatically via reflection, so hopefully provided the basic overall approach remains similar I shouldn't need to re-write too much. I'd be interested to know a bit more about the new approach to solver iterations though, since that might have an effect on how I store records of the outputs for later update...

Cheers,

Permalink Reply by Igor Mitrić Lavovski on March 29, 2016 at 12:15pm