[Twisol]

> The things which are instances of Shape are functions that accept circles or rectangles, not actual circles or rectangles.

The naming is confusing, but it's misled you in the opposite direction. Things that are instances of Shape are functions that accept handlers of circles or rectangles. The handlers, unfortunately, are named `circle` and `rectangle`. I would prefer `onCircle` and `onRectangle` in this context, because we're lacking the context of a true `match` expression to disambiguate the naming.

    type Shape = <T>(handlers: {
      onCircle: (args: Circle) => T;
      onRectangle: (args: Rectangle) => T;
    }) => T;

> Also, you seem to have created functions and types with the same names (Circle and Rectangle) which seems dangerous.

I think this is an idiom for defining a canonical constructor for a type. It's a little funky here because they're returning Shape, not Circle or Rectangle, and the latter are not subtypes of Shape. But it mostly tracks alongside the rest of the encoding.

[jameshart]

Nah, the Circle function takes an instance of Circle and returns a Shape. It’s not a constructor of circles.

The ‘exampleCircle’ is not an instance of Circle, it’s an instance of Shape.

I like the ‘onCircle’ naming though.

[Twisol]

You're speaking at the level of the code, while I'm speaking at the level of the domain. Neither of us are wrong, but we're talking past each other.

The Shape class itself is formally the sum of Circle and Rectangle -- you can think of this as a "prefer composition over inheritance" principle, but it's still a way of relating Circle to Shape. In particular, the Circle and Rectangle factories are canonical injections of these two classes into the Shape class. The naming of the factories is a little suspect, but if the only use of Circle and Rectangle is meant to be in the context of Shape, it mostly flies.

> Nah

This came across as excessively dismissive.