[cells-devel] initial stab at using Cells

[Jack Unrue]

On 4/10/06, Ken Tilton <kentilton at gmail.com> wrote:
>
> Oh, if you are big on separation maybe you can confirm something
> I suspect, namely that Cells, by allowing different instances of
> the same class to have different rules for the same slot, makes
> OO design.
>
> For example, one can have a game normally look like:
>
>    (make-instance 'game
>         :speed (c? (* (^difficulty-slider) 500))...
>
> But then for debugging a hard problem you might want to play back
> a log at full speed and so the replay code goes:
>
>    (make-instance 'game :speed 500...
>
> In the first case the game /instance/ is being driven by the GUI
> slider widget, but the game /class/ does not know about the GUI.
>
> Does that make sense in resolving the separation issue?

I'm going to assume a certain interpretation of your example that you
might not have actually intended, so if you didn't mean that the value
of (^difficulty-slider) is literally a Cells wrapper around a slider
or some specific widget type, then please by all means correct me. And
thus ignore the rest of this and just know that we'd be totally
agreeing :-)

So at the risk of preaching to the choir...

I'm not too far out of disagreement with you, but consider a slightly
different arrangement. In the above example, rename
(^difficulty-slider) to something like (^difficulty-selector). What
the renamed slot now indicates is that the "difficulty" value is still
user input but we don't specify what UI is actually used to implement
that -- it's just some mechanism for which the game logic doesn't need
to know the specifics. And at the same time, change the formula
associated with the difficulty-selector such that it's not directly
tied anymore to any particular widget type. The game UI code is
obviously responsible for translating widget events into values posted
to this selector model. So, in some respects, the name change seems
pedantic, but it's an important part of the abstraction.

By not pre-supposing what control is actually driving that slot, you
get some freedom to make UI changes that (within reason) won't affect
this game logic. For example, in version 1 the difficulty setting is a
slider, but after usability testing you realize that a slider is too
granular, and users are better served if it's just three radio
buttons. The UI code would change such that (^difficulty-selector)
values are now posted by code that manages the radio buttons, but the
game logic remain unchanged.

This facilitates the same sort of debug-mode hardcoding of the
difficulty value, again without requiring a change to the game
logic. The debug value is just another form of user input, albeit a
hard-coded value where the user is actually the programmer trying to
debug a problem.

Really, I'd bet this isn't too far from the concept you have in mind,
I'm just saying that we can abstract that a bit further. Again, that's
if I'm interpreting you correctly.

--
Jack Unrue