Hello, I wanted to ask why the Point3DList Class is within Rhino.Collections & not in Rhino.Geometry.Collections?
This seems weird to me because other Rhino.Geometry classes, such as Brep, Mesh, etc. are found within the Rhino.Geometry.Collections
thanks!
Bradley
Not a McNeel employee so I cant give an official answer, but I can guess at their thinking behind this. In my mind, a collection of 3d points is useful on a very abstract level. It could be used to wrap pretty much any arbitrary geometry, yes, but could also potentially be used for myriad other applications. You’ll notice that the classes that ARE in Geometry.collections are solidly grounded in the world of geometry (Breps, meshes, etc), and these classes necessarily have much more implicit internal structure (i.e. meshes can’t just be a flat list with no other relationships or they wouldn’t work) that makes them suitable for only a very specific application. Therefore it makes sense from an OO-programming perspective to put the Point3DList higher up in the namespace hierarchy.
This makes total sense, but following this logic, one would think the Point3D class would be higher up as well, rather than being inside geometry…
I see your point (*ahem), but as it is Point3D and Point3DList are equally “deep” in the hierarchy. Moving Point3D up one level would mean putting it in the top level Rhino namespace, which breaks the logic in exactly the same way as your original observation. I think the way they’ve done it is an optimization of two factors for each class, the “purpose (use-case)”, and the level of abstraction. As with all optimizations it’s to-may-to to-mah-to. I’m not sure that I can even convince myself one way or the other, so I’ll chalk it up to unavoidable design compromises.
All collections in Rhino.Geometry.Collections are part of geometry structures (BrepEdgeList is part of a Brep, MeshVertexList is part of a Mesh, etc. etc.). These can not be instantiated by the user of the SDK (no public constructor available), and are only manipulated from within a Brep, Mesh, Curve, etc.
The collections in Rhino.Collections, on the other hand, are “stand alone” collections and can be used/instantiated by the user of the SDK with a public constructor.
Ah, that’s a much better answer!
Thank You!@ This makes a lot of sense now.