builders.900320 (long)

[Rick Mascitti <acad!blitzen!rick>]

The following is my best shot at summarizing yesterday's
"builders" discussion.  A lot was covered but I think I've
distilled the key points.  Elucidation, refutation, addendum
are all invited.

rick

``The Builders'' discussion 900320

dean, markm, ravi, rick (joined later by hugh)

The meeting investigated whether unification of the process
of building waldos, views, and type converters was possible.

The nature of each of {manipulators, views, controllers,
models, and type-converters} was covered in depth.  Setting
aside for the moment type conversions, the objects may be
understood by the relationships view, control, and wrap.
Each object relates and is-related-by other objects and/or
by user and data.

    To view means to convert object-changed-protocol to
    some other protocol, ultimately intended for presentation
    to a user.  It may be considered a ``read-only''
    relationship with respect to data.

    To control means to convert state-change-protocol to
    some other protocol, ultimately intended to effect
    changes in data (whether local or Xanadu'd).  It may
    be considered a ``write-only'' relationship with respect
    to data.

    To wrap allows viewing and controlling with the guarantee
    of exclusivity.  No one may see past the outermost wrapping.

For a two-object relationship to be valid, one object must
accept the relationship the other gives.  All of the objects
are recursive in that they can accept and give the same
relationship.  To wit,

views:  can view or be viewed only  (outermost views may be
    considered ``viewed'' by a user)

controllers:  can control and be controlled, can wrap and be
    wrapped  (outermost controllers may be considered
    ``controlled'' by a user)

models:  can accept and give all relationships.  

manipulators:  can wrap or be wrapped only  (the innermost
    manipulator [a hand] may be considered to ``wrap'' data).


By convention, only models may have multiple viewers.
They are the only object that implements a broadcast update
protocol to those objects relating to them.

Pictorially:

key:    views <- is-viewed-by
        controls -> is-controlled-by
        wraps -[ is-wrapped-by

controller -> controller...->     ->
                             model  model...-[ manipulator ...-[
        viewer <- viewer...<-     <-


Thus it can be seen that viewers, controllers, models, and
manipulators are different beasts.  However, the mechanism
by which they are built can be similar.  Realize that in
this context ``viewer'', etc., are abstract classes each
of which has a family of subclasses for detailed semantics.
Just as concrete manipulators have structured can-wrap
chains (cf, ravi's discussion), viewer, controller, and
model instances have similar can-relate chains.  When a
client (front-end) wants a particular view (e.g.), it may
require layers of chained veiwers to be formed.  Moreover,
the requirements for dynamic creation or replacement of
standard (concrete) objects are shared.

This argues strongly for a unification of the building
mechanism, at least conceptually.

It was also realized that the same structural requirements
exist for type conversions, specifically new types created
by front ends.  In this case, the relationship is one of
converts-to/is-converted-to with respect to types known by
the back end.


** I'm not happy with the following.  Someone want to take
a crack at it?  I'm trying to describe, in general, the
appearance of the building process to a front end.**

For each of these objects there exists a ``scaffolding''
tree of standard class hierarchy that can be walked to form
the specific object requested.  At any of the leaf nodes,
a front end can register a new object to be used in the
building of object-chains.  This new object, of course, must
implement all of the protocol of the class.  This is how
the standard suite of objects is extended.