ask not what your object can do for you

[Kyle Lahnakoski]

Jecel Assumpcao Jr wrote:
> 
> Thanks Kyle, Billy and Brian for your comments in this thread.

> Note that I can have reflection in OO systems by adding reflective
> interfaces to the objects themselves (probably in class Object where
> everyone can inherit them from) or I can separate the object's main
> functionality in a "base-object" from its implementation details in a
> "meta-object". This separation is a very restricted example of Aspect
> Oriented Programming. You might argue that AOP actually reinforces
> OOness since it takes all non-menu code from the object and places it
> elsewhere. It is hard to decide.

You do seem to defeat your own point.  But maybe you are talking about a
subtle difference I can not grasp.

> We have two "schools" of objects - the Scandanavian (with Simula, C++,
> Beta) and the American (Smalltalk, Actor languages). The first one
> wants to create an accurate model of the world using the language,
> while the second is interested in learning about the world by creating
> quick and dirty models of it. One style will give you CASE, the other
> Extreme Programming.

These appear to be development techniques, and unrelated to your
previous points.  Maybe you can help me here and tell me how this ties
into the rest of your reply.  

> But we also have two different philosophies for models of the world -
> the Platonic and Aristotelian. The first considers the physical world a
> mere projection, or shadow, of the ideal world (classes are more
> important than instances, as in C++ or Smalltalk). The second considers
> the physical world the ultimate reality, though for convenience our
> brain tends to create emergent abstractions after observing common
> elements in many instances (Self or Beta).

I never thought of it that way before.  But you must admit there is a
strong correspondence between the emergent abstractions in the
Aristotelian view and the ideal world in the Platonic view.  This
bijection between views makes discussing one, or the other, useless to
solving the dilemma at hand. 

> This is a gross oversimplification, of couse. But the idea is that
> there are four distinct styles of OO programming. This isn't very
> obvious if you only look at the end results since they tend to be very
> similar. It is the roads to get there that are different.

You do want to consider both the "right" design and the paths taken to
get there.  I think you are complicating the issue.  Given a certain
amount of information, there is a correct design for it.  And we need
not consider just the formal meaning of information in this last
sentence.  Information on a domain can be artificially restricted by the
fact the human programmer can not remember all the details.  As new
information becomes available the "right" design changes.  With this
characterization of "right" design wrt the available information, we can
show the development cycle as simply the changes in available
information on the domain.  I see no problem talking about "right"
design, and development processes as two perpendicular aspects of
programming.  

I think I understand what you were saying now, and you have heard my
objections.  I am open to the possibility that there could be some
issues that can not be separated into these two aspects.  If you have,
please let me know.  



-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com