Roadmap:: Reference Models

[dcowden]

Reference Models.

This is a discussion about how reference models will be designed.

At conclusion of this discussion, we will create issues to implement Reference models.

An overview is in the roadmap document, here https://github.com/CadQuery/cadquery/wiki/RoadMap#reference-models

[dcowden]

So far, the following models have been proposed as Reference models:

1. OCC Bottle (building with wires )
2. Utah Teapot ( lots of non-planars)
3. Bearing pillow block (demonstrates simple geometry with high symmetry, and a plugin (cbore hole)
4. Analog Clock (heavy on boolean ops with faces/Sketch)
5. Soma Cube ( demonstrate assemblies )
6. Din rail

[dcowden]

I have posted a sample reference model format in this gist

each reference model would consist to two classes: one, containing a list of optional additional tests, the other, containing the specification for the reference model itself.

Feedback welcome!

[Jojain]

I have nothing to say about the structure of the ref model, this seems nice. I don't know how we could do it but add a picture of what the model looks like could be a great addition.

About this model in particular : This model doesn't demonstrate persistent naming problem. Given the fact that CQ code isnt interactive the problem cannot arise. In this exemple you fillet an edge and then do an operation that cut this edge in half, however since the fillet has been applied before there is no problem.
If you were in an interactive session and you where adding the operation before the filleting operation then in this case the filleting operation would need to detect that the 2 edges are actually the old one split in half and in this case it should update it's reference to fillet the 2 edges.
So in the end as long as we aren't in an interactive session, topological naming in that sense isn't really a concern.

[dcowden]

Thanks for the review!

For a picture, i'm imaginging that these will be built into sphix docs using a new sphinx directive, which means we'd get an interactive model like the current examples.

You're right about the naming problem! It worked out well that we can just use a simpler 'created by which tag/operation kind of approach.

[dcowden]

I have updated the reference model proposal to allow any number of examples for a given model. There are more than one way to code a given part, even using the same api. In some cases, multiple examples can demonstrate good patterns or anitpatterns