Color API Fussery

As mentioned before, I pushed back Color from 2.1.0 to 2.2.0 to get 2.1.0 released sooner. Also as mentioned, I'm trying out focusing on 1 core feature per release (with other smaller features on the side as available). So, that means the focus of 2.2.0 is going to be the new Color system.

So, what's going to be in the new sytsem? It's basically 2 parts:

  1. A variety of classes representing different color models: RGB, HSV, and HSL are planned for starters, since they are the most useful for games.
  2. An extensible table of commonly-used named colors (:red, :black, :yellow, :purple, etc.).

If I weren't so fussy, this version would be a piece of cake. I've had at least 2 nearly-complete suites of color classes dropped in my lap in the past year, and there are lists of standard color names and their RGB values on Wikipedia.

But I _am_ fussy, especially when it comes to Rubygame's API. So, I'm designing the API in a written description, without touching any code. I've learned from experience that this way yields pleasing results; I've been using it quite a bit in the Rubygame 3.0.0 development branch, designing the API before implementing it.

I've found that when you dive into the code before designing, the quirks and difficulties of the language/library you are using influence the result too much. When you don't have the plan, you make compromises, quick and easy solutions at the expense of a clean API.

So, it's back to the planning that I go.


Comments

Have something interesting to say about this post? Email your thoughtful comments to comments@rubygame.org.