[cells-devel] Re: Imperative vs. declarative

[Kenny Tilton]

Mike J. Bell wrote:

>Hey Kenny, I did a lot of thinking about what you said about
>declarative vs. imperative.  I'm not sure what's the right
>terminology, but I did finally see the light.
>
>We've had problems in applications written in our framework when there
>are multiple producers of one datum.  In a lot of cases (benign and
>simple), it's been OK.  However, as soon as things get bigger, we put
>a repeating pattern into our designs where a single controller
>function will act as a gatekeeper,...
>
Yep. I even cite such things as "prior art" of Cells, or at least other 
ways to address the issue (and serve as an existence proof that this is 
a real problem for complex applications).

> reading from multiple channels of
>data, and forming the single producer for the difficult datum in the
>previously intractable design.
>
>I've thought about it quite a bit, and I've proved to myself that this
>is equivalent to your declarative model, even if there are some slight
>structural differences*.  So, in order for me to get from where I am
>to where Cells is, all I need to do is instead of waiting for the
>multiple producers issue to get out of hand and uncontrollable...just
>nip it in the bud and don't allow it to begin with.  Then every piece
>of data has only one producer.
>
>Thanks again for talking with me about it!
>
>Mike
>
>* Speaking of structure, question for you.  Let's say you're declaring
>a slot to be a function of a couple other slots in Cells.  How do you
>know they exist?  I.e., where do you find your objects?  Do you have
>like a database somewhere (hash of name->object or the like) that you
>lookup to find things?  Are they all passed in at construction time? 
>(I would imagine this wouldn't scale well at all).  Is there some
>other scoping mechanism?
>
The Family class is an integral part of all my applications. i even have 
special handling for the kids slot (the other slot forming the DAG is 
fm-parent), though I wonder if the fixes in Cells II obviate the need 
for that. Anyway....

A suite of routines will search the Family tree of objects in various 
ways. One is by name (the md-name of a model object) and lately I have 
found myself searching more often by type "gimme the nearest Selector 
above me so I can find out if I am part of the current selection".

And I /have/ been tempted to do something with a hash table of md-names, 
but one can get a lot of duplicates on that and one is usually searching 
relative to oneself.

The nice thing about this is that it turns out that a given sought 
object need not exist when a rule requiring one of its cells fires. 
Cells would be Hell to program is that were the case. Instead, what 
happens is that the traversing finder function keeps sampling the kids 
slots of this Family instance and that. If the kids are a rule and we 
are dealing with a brand new tree of widgets, a lot of these rules will 
not yet have fired (to produce the actual kid instances). No problemo. 
Rules fire on demand, so the instances pop into existence JIT. If your 
declarative code specifies the kid being sought, it will get created JIT 
before the original rule seeking it completes execution.

I was amazed when I saw that work, btw, many moons ago.

>
>I'm not sure if Cells has any builtin support for finding the other
>objects/slots that participate in Cells, or if you roll your own per
>application...but I'd love to hear about how you solve it when *you*
>write code.
>
Check out the def-c-output KIDS method. (It might be .KIDS.) and the 
TO-BE function.

You are right: nothing says some other way of managing an object 
namespace could not be used. (Well, I /do/ have to make sure that Cells 
internals do not really need to be giving KIDS special handling... that 
may even have been an optimization or something to make debugging 
simpler "get the model population into existence first rather than have 
JIT model creation kicked off during rule fires."

kt