After being using the gh connectors intensively later, I’d like to report my feedback on the detached properties, merely as user perspective.
90% of the time I do this mistake:
“All properties are detached by default for performance reasons”
I can understand that this is true for nested (Speckle) objects (typical example of reference type data), however is this performance gain still valid for value types (integers, strings, booleans, …)? Storing a numerical property as a reference seems to be overcomplicating things.
Perhaps the “@ / detach” mark is not selected by default, but automatically appears when connecting other Speckle objects as input (but can of course still be manually overwritten)?
Hi @kelvin! primitive types don’t get detached. So if you flag an int/double/bool/etc. prop as detachable… core won’t detach it, as it doesn’t make sense as you say. Strings either, but they probably should be chunkable (different story).
Thanks for the clarification @dimitrie. From a user perspective I would say that this backs up the change suggestion above: default detachment (even when connecting primitive types) is definitely misleading.
Thanks for the suggestion @kelvin I’ve updated the docs to clarify the behavior! @AlanRynne do you think it’d be possible to have it toggle automatically when the input port is connected, based on its type?
The main problem I see with this approach is that we have no real control over what the user is going to plug into each input. It can be a single number, or a huge DataTree with a mixed bag of types (like meshes, breps, numbers and text all together).
So this would only work if the data is properly organised by type, which in an ideal world you would do to keep your sanity, but you don’t really have to using Speckle. It’s totally up to the end user.
I’m happy to be convinced otherwise anyway
On a side note, we’ll be adding the original suggestion from @iltabe on the next release. Here’s a quick sneak peek
