Solid.Split

[ikeough]

Feature Proposal

As a developer, I should be able to split a Solid created with the elements library.

Proposed API:

Solid[] Split(Plane p)

[radumg]

quick question here : should we consider making the return of this method IEnumerable<Solid> ?

reasons to consider it :

• would fit nicely with how we're structuring some of our object models, for example a Building has a list of solids (IEnumerable<Solid>) to represent its volumes
• would help with situations where we do lazy evaluation (ex : split the solids then do something else to that list) and also give developers the choice of what to do with it : ToList(), ToArray(), etc
• seems to fit in better with wider C# API ecosystem advice & nicer to work with 😎

Edit : just realised Hypar.Elements uses arrays in most places, so might be a bigger change than first appeared. If you think it's a worthwhile discussion @ikeough, could discuss moving to IEnumerable<...> in a separate issue

[ikeough]

We actually started using IEnumerable<T> in Elements, as I like it as a way of "hiding" the implementation, but then I back-tracked to using arrays. I thought having to convert ToArray or ToList to index into a collection would be an extra hurdle for the level of programmer who we are inviting to use Elements. And indexing into collections of stuff is something that we do A LOT in our line of work. Every code example that they can find anywhere, in any language, uses arrays. An example of this would be Polygon.Vertices. Previously Vertices was IEnumerable<Vector3>, so you could do:

foreach(var v in myPolygon.Vertices){...}

But if you wanted to get the first vertex you had to do:

myPolygon.Vertices.ElementAt(0) // Linq!!!

or

myPolygon.Vertices.ToArray()[0]

When what you really want to do is just:

myPolygon.Vertices[0]

Now, I agree that there are places where IEnumerable is going to be a really good choice like Truss: IEnumerable<StructuralFraming>, to be able to iterate over things that are logical collections of stuff for which the user might not expect a certain ordering. That is, I don't care about which beam is "first" in a truss.

[radumg]

Reading the release notes (see #140), this looks like it's been stealthily implemented in 0.2.1, perhaps issue can be closed if so ?

[ikeough]

It was only half implemented. I've hidden it for now because it wasn't ready for prime time, and I've flagged it for release in 0.2.5.