CreateObject component: should the BHoM_Guid property be exposed?

[epignatelli]

In grasshopper. for instance, there is no way, other of creating a Guid other than scripting.

If we are going to use the Guid as persistent id of the object, should it allowed to be set?

[rwemay]

Maybe a controversial point, in support of this, but I actually wonder if it should be suppressed by default on explode. Fine to 'get property' as people may want to see/check, but is it necessary in general/typical use-cases? Bearing in mind immutability, is not as if they're tracked in the flow-based programming environment in any case?

[al-fisher]

I think we should not be exposing or setting Guid (yet) or in its current state.
Agree with Rob - fine to allow GetProperty but -

Ultimately to make more useful and robust for user we need to migrate to the two Guid system with one Persistent. And one referring uniquely to the object instance(s) in the script. This is being looked at in the Deltas work.

I would therefore minimise exposure - on Create or otherwise - currently.

[adecler]

Ha, and I finally had a case where I was explicitly setting the Guid of the object (in node 2 code) since I needed the Guid of the nodes to match the one of the components. Sure it was in the code and not in the UI but I am never a fan of adding limitations for the sake of it. Too many time I have been frustrated with other developers for preventing me doing something I wanted to do. To 'protect' me they say 🙄

[adecler]

Should be discussed alongside of framework issues such as BHoM/BHoM#784 and BHoM/admin#9

[adecler]

Will re-open this issue if/once we have user cases justifying to add this feature