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 [EMAIL PROTECTED]
2112 Baileys Corner Rd http://www.theoryyalgebra.com
Wall, NJ 07719 732-359-6038 | 646-269-1077 (m)
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
