g = rs.GetObject("ClosedCurve")
closed_again = rs.CloseCurve(g)
print(closed_again, g) # are same
When passing closed curve into rs.ClosedCurve() returns same GUID. Wouldn’t it be more intuitive if returned GUID would refere to a copy or None? Or documetation would cover that scenario.
This happens with a number of methods, so it’s to be expected… For example if you call rs.JoinCurves(crvs) with a collection of curves that can’t be joined - or some that can and some can’t - it returns the GUIDs of the curves that couldn’t be joined as they were and does not make copies. The same for Boolean operations IIRC.
It’s always debatable how these things should work, some will say the method should always return None if it cannot be executed, others will say only if there is a logical error as in feeding an unexpected object type to a particular method…
In this case, I guess I would just filter out the closed curves to begin with.
Sure i can filter our closed curves before or test whether old and new curve are sharing same guid. That said looking it from flow perspective this function is branching in 3 different way: 1. Curves, which are joined, 2. curves which can not be joined and 3. curves which are not changes. Comparing it to rhino SDK counterpart Rhino.Geometry.Curve.MakeClosed() which returns False only when it is not possible to close curve. Alternatively curve is modified and I do not have to think about conditions. Layer of abstraction should not introduce more ambiguity.
I don’t want this function to be change just note in documentation.