[cells-devel] More newbie questions

[Mike J. Bell]

Kenny Tilton <ktilton at nyc.rr.com>
On Sun, 06 Mar 2005 15:55:29 -0500, Kenny Tilton <ktilton at nyc.rr.com> wrote:
> Not sure what code you are referring to. I would not have the slider set
> the zoom, I would give the zoom a rule which watched the slider value,
> which would just go from zero to one. When the new requirement came
> along I would simply have the zoom rule look at the slider /and/ the
> sample rate. Seems easy enough to me, and more self-documenting than the
> approach you described. If the zoom value is coming out wrong, I like
> knowing without doubt exactly where to look. Hell, in the inspector I
> can even look at the code, which for debugging purposes I store in
> symbolic form in the Cell for those cases where a slot gets different
> rules for different instances so often that it is painful to work out
> which rule applies to some instance I am debugging.

Now this I have to disagree with, from a design perspective.  The zoom
level in my application is used in at least 8 different unrelated
subsystems.  It's also controlled (changed) by 4 different GUI
widgets.

Having the zoom be calculated based on the value of a GUI slider (oh,
and I was wrong, I was actually thinking of a combobox/list now, but
close enough...sorry) really points the arrow in the wrong direction,
in my opinion.  The current zoom is the leader of zooming!  The actual
current zoom level is the piece of data that "feeds" any part of the
rest of the system...including the GUI widgets that set (or attempt to
set in some cases) its value, the GUI panels that actually display the
audio data at the appropriate resolution, to the scaling functions
that allow time markers to be created based on mouse clicks.  The
other pieces of related data (current selection in the combobox/list,
slider pixel value, etc. etc.) are all dependent.

I think this is the spirit of what I was getting at:  when the data is
decoupled from the functions that act upon it, it's much easier to
realize a true model-view-controller architecture.  If you decide to
replace the slider in your example, the zoom code has to be rewritten
to be calculated based on whatever widget you decided to change it to.
 If your functions are separate from the data, all you change is the
GUI widget function...all the other pieces stay intact, and still work
as originally designed.

Of course, that's the key...now your application is (more than ever)
tied to the proper design of your data model.  If you didn't design it
properly to begin with, or your original cut wasn't resilient enough
to cope with change, or your changes are overwhelming and incompatible
with your original design...then you've got to change a bunch of
things.  But that's true for every programming style.

Now it's entirely possible that what you described could be refactored
into a much more loosely coupled version, I just haven't thought about
it enough and I'm not familiar enough with Cells to know how to do
that.

> I am not saying I do not find constraint programming interesting or that
> it would not be fun to simply drop a new rule in the basket as a way of
> modifying a program. On the other hand, I have heard nothing but
> nightmares about what it is like to program with multi-way and partial
> constraints, so I have not been tempted to add anything like that to
> Cells (so far <g>).

What I've (we've, I guess) found with the system I'm using now is that
having tools that can display to you your application topology (not
necessarily in a nice beautiful GUI app) and also categorize/classify
the interactions between the data and functions that act upon it is
absolutely essential.  I would imagine that any application of
sufficient complexity would benefit from this of course, but since
ours is imperative (to a certain degree) and forms a very complex
publish subscribe network, it's mandatory.  There are interactions
that are impossible to reason about without program introspection. 
I'm not sure if this is a really bad thing, considering that most
applications written in the world (without the benefit of a framework
like Cells or ours) have tons of undiscovered bugs that are thousands
of times harder to find.

I'm going to keep thinking about declarative event handling vs.
imperative event handling.

Thanks again Kenny...

-- 
Mike J. Bell on gmail