Seeing as draw.color has no subclasses except Set and Get is would be stupid to make the library 'draw' with the sublibrary 'color' only to hold the classes 'set' and 'get'...
Even better would be draw.color.set() and draw.color.get()
If one has those functions for color, it wouldn't be that far-fetched to apply them to the drawing color as well. After all, if color is a class, all color methods go in that class.
And of course, if I define a new variable of type color, than all methods should apply to that variable as well.
Again, not sure this is what I'd like to work with though. I think the current method is clearer for novices, because you have a function and that's it
. I think for non-programmers the idea of a function that "does stuff" is easier to grasp than the idea of a "method" that does stuff within a "class" of a certain "type".
I'd like a variable draw_color instead of functions, and then just use the color functions on that variable, and being able to assign values to the variable (draw_color = c_red).
Colors should be passed along in the drawing methods instead.
Instead of setting the color once and then drawing a load of stuff, you suggest that each and every draw call we have to re-enter the color? Why not do the same then with alpha and blend mode, circle precision, interpolation, and in d3d the fog, lighting, culling, hidden settings? Functions will have a whole lot of repeated arguments. Not sure I like that approach. But maybe it makes things clearer by leaving out "hidden arguments". I find that happens a lot with the _set and _get functions. I find myself frequently thinking "is culling on or off here? Oh well, let's just set it how I want it here.", ending up with a lot of unnecessary _set functions. Mainly in d3d though.
I don't know.