scadla icon indicating copy to clipboard operation
scadla copied to clipboard

[WIP] Typeclasses all the way!!!

Open tg44 opened this issue 5 years ago • 6 comments

Hy!

First of all nice lib!

Second: What I was not really liked here is the coupled solid-renderer code. When I tried to add new openScad capabilities, everything started to get messy. So I started to refactor the code with Typeclasses, and bcs I reached a point when I see how it goes, I want to ask your opinion if its an improvement or a drawback.

The basic idea: Instead of a big match-case in every renderer, we need to implement Renderer[A] classes. So we would know at compile time for example if JCSG could render a BeltMold.inner or not.

The pros:

  • We don't need inheritance anymore, everybody can implement everything in separate libs for example.
  • We can add multiple implementations to the same object if in some renderers there is a build in support for it (for example we can build a more optimal centered cube).
  • We know if the renderer can or can't capable of rendering the given object.
  • It's not breaking the already written (model) code (or at least it only needs minimal modifications check the test-code in the first successful render for reference).
  • We can create "renderer exclusive" Solids, so we could use for example already written openscad code with "copy-paste"

The cons:

  • The new "general model" codes are polluted with a lot of implicits (check the last commit for example)
  • IntelliJ sometimes highlights wrong (it hates the + operator)
  • More magical scala errors (bcs of implicit helpers of implicit converted implicit implicits :D )

Basically the first 3 commits are the interesting ones.

  1. The first is just baselineing with some outputs, so later I can cross-refactor the old and new renderers.
  2. The second is the openScad implementation with the new typeclasses, and the first test which was the WhiteboardMaker.top func "copy-pasted".
  3. The third was a gateway between the "old" renderers and the new one, the new classes can be implicit converted to the Solid counterparts, making the next refactors more friendly (it would be more nastier without it, but its still a mess)
  4. Making our first test using the same infra with both renderers
  5. More implicits
  6. A lot more implicits :D

The next steps if we move forward:

  1. copy + refactor the other baseline tests
  2. refactor all the utils
  3. refactor all the examples
  4. rewrite all the renderers
  5. remove all the .toSolid calls
  6. remove the old Solid, and old renderers

I would like to hear the authors voice before I move forward, or give up :D I reached the point when I think that for the stuff I want to do, (and with the code I already written) I would be ok in a separate project too. But it would be nice if I could contribute to an existing thing and not reinvent a concurrent just bcs I was lazy to refactor :D

(Also this could be a good reading if you are not familiar with it: https://tpolecat.github.io/2015/04/29/f-bounds.html)

tg44 avatar Aug 22 '19 18:08 tg44