Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

jhd@herold.franken.de (Joachim Durchholz) writes:

>> execution of a program.  And in a Self program, classes never exist at all
>> (not even in the program text).

>Well, I don't know Self (or any other prototype language), so I'm a bit  
>bewildered about what you say about this statement.
>Could anybody post a short characterisation of prototype languages?

Here it is in one line:
    - objects inherit methods and fields from *other objects*.

In Self, for example, an object is a collection of named slots, some of
which contain methods, some of which contain data, and some of which
contain references to other objects called "parents".  An object need
not have _any_ parents, may have one, or may have more than one.  If
a slot is needed for an object that doesn't directly contain a slot
with that name, the parents are searched.  A parent slot may be changed
at any time, so "mycar" may reparent itself from "vehicle" to "scrap_metal"
at any time...

>Not in all cases. Most OO languages have abstract/virtual/deferred classes  
>that primarily serve to specify external behaviour, not implementation.

In the OO languages I am familiar with, nothing prevents an abstract
class providing implementations of _some_ of its methods, and this is
very often done.

>I definitely agree that inheritance can be used for code sharing, but it  
>is also useful for object classification.

The trouble is that there are applications where the way an object should
be classified (without changing its identity) varies with time.  And
even when that doesn't happen, the two hierarchies don't necessarily line
up perfectly (which is why Java has both 'interfaces' which refer to
`is-a' and 'classes' which refer to `is implemented using parts of').

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.