Hi all,
The answer is yes or no depending on the observer's mindset.

A Smalltalk object has a unique identity and encapsulates state and 
behavior. Objects in its environment can know its identity and send 
messages to it. There is no restriction; an object can receive any 
conceivable message. Inside the encapsulation, we find instance 
variables and methods. An object selects and invokes a method in 
response to an incoming message. (The |doesNotUnderstand:| method is one 
of them).

An isolated object by itself is not interesting.
The essence of object orientation is that objects interact to achieve a 
task.
A person who wants to understand how a system of objects works, needs to 
answer three essential questions:
"What are the objects?" "How are they interconnected?" "What do they do?"

/Are objects really hard?/
The answer is YES for a person having a class-based mindset. The class 
abstraction describes all the properties of an object that are visible 
when it is observed from its inside. Its environment is outside its 
encapsulation and is not visible in the class description.  Anybody 
trying to answer the above three essential questions by studying a class 
is doomed to failure. Objects are really hard for such people.

/Are objects really hard?/
The answer is NO if the question is asked by a person having an 
object-based mindset:

    * Alan Kay's schoolchildren had no problems with interacting objects.
    * My company developed object-based models for different clients
      using role modeling (OOram). Again, there was no problem with the
      idea of interacting objects.
    * Many developers use CRC cards to elucidate object-based mental
      models shared by users and developers alike. Again, CRC cards are
      easy to understand. (A note here. CRC originally was short for
      /Class-Responsibility-Collaboration/. This was a misnomer since
      classes do not collaborate, their instances do. People think
      instance even if they say class. Today, the letters stand for
      /Candidate role-Resonsibility-Collaboration/. [Rebecca Wirfs-Brock])
    * In their book  "Lean System Architecture", Coplien and Brøvig
      recommend programmers to work closely with users to elucidate an
      object-based system architecture.
    * A growing community of programmers understand the DCI paradigm and
      have an object-based mindset. DCI (Data-Context-Interaction)
      includes both mental models and actual code. It is interesting to
      note that many members of this community started out with a
      class-based mindset. As one should expect, changing a mindset can
      prove very hard. After the hard work of the transition, objects
      became very simple..

In Smalltalk, anything anybody will ever want to represent in the system 
will be represented by an object. There is no alternative. The image of 
objects rests on top of the VM. A few of these objects are special in 
that the VM knows the position of certain key properties within the 
object. Instances of class Class are such objects where the VM knows how 
to find the |methodDict |and other properties. Examples are the 
properties the VM needs to create a new instance. There are other 
special objects such as |CompiledMethod |and |SmallInteger|. It is 
interesting to note that there is no such thing as a "Smalltalk 
language" in the same sense that there is a Java language. There is a 
default language for specifying methods in the context of a class. Its 
compiler is actually a method in the metaclass. Other classes can 
support other languages. VisualWorks had classes where the methods were 
written in SQL.

There is nothing in Smalltalk that makes class-based programming 
mandatory. It makes me sad to think of all the opportunities that have 
been lost through the past 40 years due to this wholly arbitrary 
restriction.

Cheers
--Trygve


-- 

Trygve Reenskaug       mailto: trygver at ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120214/a0939856/attachment.htm