[CSG]: consistent abstractions for primitives and colors
Opened this issue · 5 comments
The situation in csg and rune is quite similar. We have primitive shapes (including an empty special case) and a way to color things. The two libraries go different routes in this.
csg provides the colors as constants and the primitive shapes as functions that are applied to colors, and rune provides the primitive shapes as constants and the colors as functions that are applied to shapes.
I feel that consistency between the two is more important than which way we go. I would like to replace some rune missions/quests with csg missions/quests, so consistency across these two modules is particularly important.
It's exciting to hear that CSG may see use in lessons. The way CSG handles colours has gone through a few changes, but it would definitely be feasible to make CSG match rune in terms of usage. That would probably also reduce the amount of work needed to update existing learning materials for rune. After which it would make even more sense to rename CSG's empty_shape to also be blank.
Just leaving a note here that the CSG module summary & sample snippets would also need updating to the new usage.
Another note, we could bring back silver as the default colour.
See also previous PR comment.
There may actually be good reasons for the difference between rune and csg: The design of csg does not support making a new shape that is derived from an existing shape but has a different color. The design of rune explicitly supports this: red(whatever_rune) returns a rune that is entirely red, regardless of the colors in whatever_rune.
So in order to provide a consistent handling of colors, we would need to limit the functionality of rune. Any comments whether we should do that?
Iirc, CSG used to have such functionality in an earlier version. That is, taking in a shape as well as a colour, and returning a new shape entirely in that colour. It should not be too hard to bring back as a feature using JSCAD's colorize(). Perhaps by (re)adding a function to CSG called color(), alongside the mentioned change in syntax to have its default colours be functions and its primitives be values. That would make CSG match rune, without having to limit rune's functionality.
@Cloud7050 raises the prospect of a color() function for CSG. With that, we could make CSG consistent with runes. How much work would that be?
Barring unforeseen challenges, I'm thinking some hours to update the existing colours/primitives, add the colour function (probably a few lines), bring back the default colour, and update documentation. This is assuming the JSCAD functions and the current design of CSG doesn't require us to do extra work to ensure colouring the passed shape returns a new shape without mutating the existing shape. There is also interactions with colouring groups to consider.
It would then take more hours to do testing and to update the existing samples. In all, maybe 1-2 days of dedicated work for a modules developer with some familiarity.