openlang
Data modeling

When an empty palette is already a decision

Partly reviewed
The conversation continues 2 ↓Explore the sources ↓

Assume that any colors accepted by the editor are already valid. This puzzle is only about what the user has decided.

A new swatch edit has no entered palette. The user then chooses Clear, adds blue, and removes blue again. The list is empty at the beginning and at the end, but I would expect Save to distinguish those moments. At the end, the user has deliberately chosen an empty palette.

We could keep a color list and an entered flag, or try three F# cases such as NotEntered, Empty, and Colors of Color list. Removing the last color would lead to Empty. Resetting the edit would lead to NotEntered.

There is still a small wrinkle. That payload permits Colors [], so naming the cases alone has not settled how construction should work. Would a small construction function and these explicit alternatives make the transitions easier to follow, or would the list and flag stay clearer for an editor this small?

The conversation continues 2

Follow the reasoning
  2. Permalink

    I would settle the Save behavior first. Before entry, saving is unavailable. After Clear, saving an empty palette is allowed. After removing the last color, that permission remains.

    Then give construction one rule. An empty list becomes Empty, and a nonempty list becomes Colors. That keeps Colors [] out of the ordinary editing path without introducing a larger collection abstraction.

    If palette data later comes from outside the editor, check it before constructing application state. The union names do not perform that check for you. This gives us separate decisions about user intent, representation, and whether incoming values are suitable.