Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!dean
From: dean@image.soe.clarkson.edu (Dean Swan)
Newsgroups: comp.object
Subject: Re: Should Shapes Display Themselves?
Message-ID: <1990Aug13.003442.29955@sun.soe.clarkson.edu>
Date: 13 Aug 90 00:34:42 GMT
References: <26011@bellcore.bellcore.com>
Sender: dean@sun.soe.clarkson.edu (Dean Swan)
Organization: Clarkson University, Potsdam, NY
Lines: 75

>> Leaving aside objects which are explicitly intended as display
>> artifacts (windows, menus, etc.) and considering application domain
>> objects such as personnel files, tractors, and fishing boats, should
>> these objects be concerned with how they are displayed or should we
>> separate the objects (models) from views?

What I've seen here so far is this:

   1) Mechanism *should* be separated from policy.
   2) Objects *should* be able to display themselves.
   3) Having separte 'view' objects would destroy the encapsulation
      provided by an object.

Statement #1 is true.  Statements #2 and #3 are false.
The advantages of separating mechanism from policy have been expounded upon
enough, so I won't reiterate what others have already stated.

As to Objects being able to display themselves:  The major reason for an
object to be able to display it self is for performance reasons.  Other than
that, this is a big violation of the mechanism/policy separtation rule.

Think about how we visually percieve things in the real world.  Light (which
for purposes of this discussion can be considered and object) emanates from
a source, travels some path, reflecting off an object, and into our eyes.
The light has characteristics (intensity, color, coherency, velocity (a
vector quantity), etc.) so it can reasonably modeled as an object, and of
course a page in a book, or whatever we are viewing can also be modeled as
an object.  A light source could send an illumination message to an object,
and the object could send a reflection message to the camera, eye, etc.

Of course this gets horribly complex, very quickly, and we don't need all
of the functionality that the real world model provides most of the time,
so we start to make simplifications/optimiztions for the limited set of
circumstance that we require.

In a previous example, somebody mentioned a 3D graphics system, and the
question was raised "How should an object know if it is obscured by
another object?"  It shouldn't!  How do we know that atoms have dense nuclei,
and orbiting electrons?  Because Rutherford was able to shoot aplha particles
"through the holes" in a piece of gold foil, but even this is only an
educated guess with enough supporting evidence that we accept it as fact.

Someone else suggested using an intermediate display language to implement
'drawMe'.  This is a step along the right vector, but in the wrong direction.
Objects should be able to respond to a set of messages that provide a 'view'
object enough information to render the object.

The problem with this idea is that there are too many possibilities to be
able to practically design a standard set of messages that all objects can
respond to, to make them 'view-able' in any context that a user could wish
for.

So that leads us back to 'Yes, ABSOLUTELY, objects should be able to
display themselves.' and it comes full circle.

I would put forth the idea that the major reason that mechanism and policy
do not remain strictly separated is that performance considerations frequently
outweigh the advantages of separating mechanism and policy.

A good comparison is separation of church and state.  The rule is that they
must remain strictly separate, but there's another rule that says people must
be free to practice their religion.  Well, should children be allowed to pray
in schools funded by the state?  According to the first rule, no they should
not.  According to the second rule, yes they should.  And the real world
solution is to allow it to be dealt with independantly for each 'instance'.
(And by using the word 'instance', I do mean to imply the concept of
 instantiation - the result of: SomeClass new.)

Ok, I've babbled long enough.  Am I making any sense?

-----------------------------------------------------------------------------
Dean Swan
dean@sun.soe.clarkson.edu
-----------------------------------------------------------------------------