Re: Alan Kay on the meaning of "object oriented"

[tjoccam@xxxxxxxxxxx]

> Hi Larry,
> One of the better descriptions of objects and classes I've seen comes
> from Bertrand Meyer. He describes classes as "abstract data types
> equipped with a (possibly partial) implementation". An object is a
> run-time instance of a given class. So, while you are correct that an
> object is in most cases basically a data structure and some
> associated procedures, that rather misses the point. The key aspect
> of objects is that they are not just arbitrary data structures with
> arbitrary procedures, but instances of a type (the class) with a
> prescribed interface. The OO approach involves designing software
> that is (ideally) implemented as a collection of interacting ADT
> implementations. Although it's certainly possible to implement
> abstract data types in non-OO languages, an OO language provides
> facilities for controlling encapsulation, treating implemented ADTs
> as modules, treating ADTs as types within the type system, safely
> constructing and manipulating ADT instances to preserve invariants,
> and for defining certain ADTs to be subtypes of other ADTs via
> inheritance (which in turn allows objects that are instances of the
> subtype to be treated as instances of the supertype when appropriate,
> and to do so in a type-checked manner).

This pretty much fits what I understand - and does not fit the Alan Kay
notion (which is more like a process). Where the OO stuff makes sense is
in clear analogies --- for instance, mathematical types (which can be
generalized to more than the bit size of the processor, or even unlimited
bit size - or oddball bit size - and still naturally have "methods" such
as addition and multiplication that exhibit clear analogy in their
behavior, e.g. overflow). But even that can get into trouble (dividing
matrices?). And the key to the mathematical objects is they have a very
well defined usage of resources (i.e. just CPU and memory, and if done
carefully, limited scratch such as stack). And the subtypes (which are
super-structures, i.e. structures containing more than the parent type
structures) become dangerous when STRICT analogy is not maintained.

>
> I don't particularly want to get into all of the arguments for the
> use of an OO approach. I think that Bertrand Meyer presents a good
> case for developing software based on classes and objects in his text
> "Object-Oriented Software Construction", and I encourage you to dig
> up a copy of that book if you want to get a better idea of what all
> of the fuss surrounding OO is about. Note, however, that what Meyer
> describes is how things *should* be done in OO development, not
> necessarily how what passes for OO development in many organizations
> is actually done. It's probably also worth noting that many of
> Meyer's arguments are probably equally applicable to a process-
> oriented design approach, and that the approach to OO concurrency
> advocated by Meyer is explicitly influenced by CSP (both CSP and
> occam get several mentions in his book).

I think OO and processes are actually orthogonal, with OO (as you defined
it) being a technique for organizing (abstract) data assemblages, and
processes (or Kay's objects) being a way of organizing (concrete)
resources. Unfortunately OO is made to expand to include state machines
(open, read, malloc, etc).  Then inheritance becomes metaphoric and not
analogical (hidden side effects, differences in behavior, dependencies).
OO (or any other data organization technique) should be a layer on top of
the process harness. That has always been my design attack: get the data
flow working with completely unrestrictive "null" algorithms or methods
(doing nothing except, possibly, forcing delays equivalent to the real
task); then, once that is robust, do the (comparatively easy) task of
adding the real computing.

Larry Dickson

>
> By way of a disclaimer: I am not an OO zealot. I think OO is a useful
> model, and that there are uses for it. But I don't think it's the
> magical cure for all ills that it's sometimes touted as, and I don't
> think it's always the right tool for the job - I prefer to choose the
> computational model that best suits whatever problem I'm trying to
> solve.
>
> Cheers,
> Allan
>
> On Nov 13, 2007, at 8:31 AM, tjoccam@xxxxxxxxxxx wrote:
>
>>> He said that "Simula said that data-structures and procedures are bad
>>> ideas". This was fantastic! he said. One wanted objects which
>>> themselves
>>> knew what to do. The basic idea of OOP is "wrap it up and make an
>>> API out
>>> of it".
>>>
>>
>> Hi Oyvind,
>>
>> Correct me if I'm wrong, but isn't an object a data structure in
>> disguise,
>> and a method a procedure call in disguise? And isn't an API a
>> procedure
>> library? I don't know Simula, but all the OO stuff I have ever seen
>> just
>> seems to be data structures and related procedure/function
>> libraries, plus
>> long lists of restrictions on their use and relatedness trees among
>> the
>> structures based on shaky metaphor.
>>
>> Larry Dickson
>>
>
>
>