Constructors: primitive types or domain types? Or both?

[danoneata]

The following discussion doesn't have a high priority, but I wanted to say it out loud since it was on my mind for some time already.

When deciding what arguments can be passed to a function, we have to choose between using primitive Python types (such as str, tuple, float), for example,

circle(1).fill_color("red")
Path([(0, 1), (2, 0), (3, 0)])
square(1).rotate(90)

or domain-specific types (such as, Color, P2, Degree):

circle(1).fill_color(Color("red"))
Path([P2(0, 1), P2(2, 0), P2(3, 0)])
square(1).rotate(Angle.from_degree(90))

The former are easier and more direct to use, the latter are more flexible and more precise. Currently, we use various techniques for supporting multiple types (e.g., union types, as done in arc_between; multiple constructors, as done in Path; or multiple methods, as done in Transform), but maybe we should settle for a more uniform approach? For example, I am happy with using union types, as I see it is quite common in other Python libraries. I for one would like to be able to pass strings for colors instead of instances of Color 🙂

[srush]

Just saw this. Think this is good for colors as the API surface is small.

For P2/V2 though there are a lot of functions that take those args, and might be annoying to convert them everywhere. 2 ideas.

1. internally we don't use P2/V2 in oop style, but simply treat them as tuples and apply transform functions directly. (V2 inherits from tuple already). P2 becomes an alias for tuple.

2. we make P2Like = tuple | P2 and call a convert function on every function a user could call.

For degree / rad / turns we could experiment with newtype.