[Grace-core] Fwd: [squeak-dev] Are Objects really hard?

[Kim Bruce]

Interesting, and (believe it or not) I agree with most of what is said here.  Classes are merely an implementation technique for creating objects and thus are only peripherally related to the use of objects.  Instead, the types of the objects they generate are key to understand interaction.  It's one of the reasons that I believe a good intro course will generally start with a collection of pre-built objects (generally generated by provided classes) that can interact with each other and where the students have little or no knowledge of the actual implementation.  Types provide the abstraction barrier -- and perhaps go even further by telling the student that if you want to use these objects there is little or nothing useful to be gained in trying to dive inside.  (Obviously there is much to be gained if you are trying to implement your own objects -- which you eventually will).  At the beginning the students' focus should be on how to use these interacting objects, with the focus on how to build them coming after they understand how to use them.

... and while some of you will no doubt disagree, I find that type systems help me and my students keep the focus on what they can do, rather than the details of their implementations.

Kim



On Apr 19, 2012, at 8:17 AM, Andrew P. Black wrote:

> An interesting message from Trygve that popped up today while I was searching for something else.
> 
> 	Andrew
> 
> 
> Begin forwarded message:
> 
>> From: Trygve Reenskaug <trygver at ifi.uio.no>
>> Subject: Re: [squeak-dev] Are Objects really hard?
>> Date: 14 February 2012 10:04:25 PST
>> To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
>> Reply-To: trygver at ifi.uio.no, The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
>> 
>> 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
>> 
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20120419/699eeb6f/attachment-0001.html>