[cells-devel] Question about families and kids

[Ken Tilton]

Josip Gracin wrote:

> Thomas F. Burdick wrote:
>
>> you need a suite of tree- or net-searching utilities to really enable
>> the declarative style that makes Cells such a win.
>
>
> This is what I don't actually understand.  I'm writing a simple 
> aircraft simulator and I have a bunch of defmodel definitions for 
> various systems, a bunch of input and output cells and I expect output 
> cells to provide new values whenever their dependencies are changed.  
> Currently, this all works beautifully for me and I haven't used any 
> explicit network modeling/searching.  I'm wondering if I am missing 
> something.
>
> As an example, I have something like the following:
>
> =================================================================
>
> (defmodel flight-parameters ()
>   ((speed :initarg :speed
>       :cell t :initform (c-in 0) :accessor aircraft-speed)
>    (altitude :initarg :altitude
>          :cell t :initform (c-in 0) :accessor aircraft-altitude)
>    (heading :initarg :heading
>         :cell t :initform (c-in 0) :accessor aircraft-heading)))
>
> =================================================================
>
> (defclass aircraft ()
>    (flight-parameters :initarg :flight-parameters
>               :accessor aircraft-flight-parameters)
>    (lights :initarg :lights
>        :accessor aircraft-lights
>        :documentation "Light system.")
>    (light-switches :initarg :light-switches
>            :accessor aircraft-light-switches)
>    (flaps :initarg :flaps
>       :accessor aircraft-flaps)
>    (gear :initarg :gear
>      :accessor aircraft-gear)))
>
>
> =================================================================
>
> (defmodel b777-flaps (flaps)
>   ((lever-position :cell t
>            :initarg :lever-position
>            :accessor flaps-lever-position)
>    (real-position :cell t
>           :initarg :real-position
>           :accessor flaps-real-position)
>    (transit-start-time :cell nil
>                :initarg :transit-start-time
>                :accessor flaps-transit-start-time
>                :initform 0.0)
>    (transit-start-position :cell nil
>                :initarg :transit-start-position
>                :accessor flaps-transit-start-position
>                :initform 0)
>   (:default-initargs
>       :lever-position (c-in 0)
>     :real-position (c? (flaps-real-position-fn self))))

What your example does not show is how one model instance finds another 
instance. In my Family-based code I have functions that search the 
family DAG by name (where the .md-name slot is "the name") or by type. 
The advantage is that I do not have to know exactly where in the tree 
something is, it just has to be somewhere. A radio button is on if the 
nearest radio-group-manager instance searching up the model has the 
radio button's value as its value. The coach widget is visible if the 
check-box named :show-coach has a value of t. etc etc.

Your model will have cockpit controls that make rudders and other 
surfaces move, and indicators that show their position. Now you can 
write code for the indicator for landing gear #5 that says  (position 
(aref (landing-gears *plane*) 4)) and you will be fine, but some of your 
"finding" is being done with a special variable that needs maintaining 
and some of it is being done with a hard-coded API (you are relying on 
the landing-gears function knowing where to find them on the plane -- 
does the plane own them, or are they nested components of an intervening 
"frame" subcomponent?) In the latter case if you redesign the OO model 
for the plane, all the functions hard-coded to locate other instances 
have to be revisited to see if they still hold. So that code is a little 
brittle, more so the more you are into refactoring.

Especially in a GUI, I might decide to add a second button alongside a 
first button. So now I put a row widget in the view hierarchy where the 
first button was and it gets two kids, the first and new second button. 
Any interwidget dependencies are fine, because searching by name or type 
they will still find each other (within the capabilities of the Family 
navigational tools).

hth, Ken

-- 
Ken Tilton                   
Theory Y Learning        ken at theoryyalgebra.com              
2112 Baileys Corner Rd   http://www.theoryyalgebra.com     
Wall, NJ 07719           732-359-6038 | 646-269-1077 (m)