[squeak-dev] history of ideas: subclass responsibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] history of ideas: subclass responsibility

Stefan Sobernig-2
Dear Squeakers,

(sorry for cross-posting; already posted to comp.lang.smalltalk)

For a piece of research I am currently working on, I have been
reviewing the arsenal of publications on the genealogy of Smalltalk(s)
for some hints on the origin of the
Smalltalk-specific "subclass responsibility" approach, i.e. the
Smalltalk dialect for "abstract object-classes",
roughly speaking. I am particularly interested in references to design
decisions. It would be particularly enlightening to know
whether the Xerox crew was aware of the "virtual quantity" feature
introduced in Simula-67 and their perception (beyond the mere difference
with respect to type checking). I do have thoroughly
studied "original" Smalltalk-related contributions, far beyond the
Blue Book, but could not find explicit references beyond the mere fact
that this is the Smalltalk way of doing it; but why?

Note that I am well aware of more recent discussions on that very
matter, especially in your community on the semantic consistency of
subclassResponsibility:

http://wiki.squeak.org/squeak/472

I am also aware of other language families that approach the idea of
deferred-required implementation by means of a /placebo/ (what I would
call it as a strategy).

Over at comp.lang.smalltalk, I was given as part of a more thorough answer:

> Because we also need a way to respond
> for the general case of a message received
> that is not understood.

So, abstract super-classes are considered a special case deriving
from a more general issue.

Is anybody aware of some nuggets out there? I would be grateful for
any hint + your thoughts when looking at your languages' history ...

Best,
//stefan

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: history of ideas: subclass responsibility

Klaus D. Witzel
On Sat, 02 Aug 2008 17:45:03 +0200, Stefan Sobernig wrote:

> Dear Squeakers,
>
> (sorry for cross-posting; already posted to comp.lang.smalltalk)
>
> For a piece of research I am currently working on, I have been
> reviewing the arsenal of publications on the genealogy of Smalltalk(s)
> for some hints on the origin of the
> Smalltalk-specific "subclass responsibility" approach, i.e. the
> Smalltalk dialect for "abstract object-classes",
> roughly speaking.

Interesting question (origin) indeed :)

> I am particularly interested in references to design
> decisions. It would be particularly enlightening to know
> whether the Xerox crew was aware of the "virtual quantity" feature
> introduced in Simula-67 and their perception (beyond the mere difference  
> with respect to type checking). I do have thoroughly
> studied "original" Smalltalk-related contributions, far beyond the
> Blue Book, but could not find explicit references beyond the mere fact
> that this is the Smalltalk way of doing it; but why?
>
> Note that I am well aware of more recent discussions on that very  
> matter, especially in your community on the semantic consistency of
> subclassResponsibility:
>
> http://wiki.squeak.org/squeak/472
>
> I am also aware of other language families that approach the idea of  
> deferred-required implementation by means of a /placebo/ (what I would  
> call it as a strategy).
>
> Over at comp.lang.smalltalk, I was given as part of a more thorough  
> answer:
>
>> Because we also need a way to respond
>> for the general case of a message received
>> that is not understood.
>
> So, abstract super-classes are considered a special case deriving
> from a more general issue.

What I always liked are the paragraphs between "Inside every large program  
there is a small program trying to get out. ?C.A.R. HOARE" and "In  
class-based object-oriented systems, partial implementation is usually  
supported in the form of abstract classes." in the paper linked below.

What I mean is the emphasis on partial, incomplete implementation, made  
possible by late binding, a valuable tool for incremental development and  
maintenance.

> Is anybody aware of some nuggets out there? I would be grateful for
> any hint + your thoughts when looking at your languages' history ...

Perhaps there are some nuggets in the paper from which the above was cited,

- http://portal.acm.org/citation.cfm?id=243439.243441

/Klaus

> Best,
> //stefan
>
>