Grasshopper has to be able to do a certain amount of things with the data it handles. These include (but are not limited to): formatting and parsing, conversion to other types, serialisation, validity tests, previewing/baking.
IGH_Goo is an interface that adds some of this functionality to any data type, so GH can handle
System.Boolean as well as
Rhino.Geometry.Brep as well as some plug-in defined type that was designed after GH was compiled.
Also, all data in GH must be nullable, which excludes storing value-types such as
Color directly in lists, because those are never null. By demanding an interface implementation, it turns all data into reference types.
The major downside to this approach is that it basically doubles the amount of types involved, you have to deal both with the underlying type and the goo wrapper type. This makes for a lot of additional checking and complication when writing -for example- type conversion code.
There’s other fairly significant downsides too which is why I’ve ditched this approach in Grasshopper2. Under the new system data is stored directly as is (with an optional synchronised collection of bools signifying null-states if necessary). All the functionality needed by GH to handle the data will be provided by a completely separate class, only one instance of which will ever be constructed. These ‘type assistants’ as I’ve called them will provide a much wider array of functionality than
IGH_Goo ever did.