[Shootout-list] Re: OO (was Re: process creation & message passing)

[Aaron Denney]

On 2004-10-22, Isaac Gouy <igouy2@yahoo.com> wrote:
> There are better forums for debating what OO is and isn't - like
> comp.lang.object (although it's a conversation they grew bored with a
> decade ago).

True enough, but we're not debating what is OO, but what this test
should test.

>> > Shifting judgement onto the test is just going to make it more
>> > difficult to write benchmark tests and more difficult to write
>> > programs that meet them. 
>> 
>> Simple: the object system used must allow dispatch to be controlled
>> by the type of the object, and adding new types of objects must not
>> involve altering the dispatch mechanism or global mapping tables.
>
> That's a criteria we could choose to judge if a program is acceptable -
> just like saying there should be object identity, encapsulation,
> subtype polymorphism - but you haven't shown how to make it part of a
> test.

Oh, I finally get what you were saying.  I didn't mean to propose that.

In the same sense that spitting out the right text is, trivially
checkable by scripts, no, it's not checkable by the test.

But a lot of things already aren't.

>  
>> I don't think subtyping (either explicit or implicit) is the
>> definitive distinguishing feature of OO -- consider Smalltalk or
>> Objective-C where all objects can receive all messages (though they
>> may respond with a "does not understand" exception).  In that sense
>> everything is a subtype of everything else.
>
> Let me suggest there's no-such-thing as "The" definitive distinguishing
> feature of OO - 3 distinguishing features I could believe.

That's a reasonably orthodox suggestion.  It's just that I have a hard
time believing it.  Polymorphism (though not necessarily "sub-type"
based in any useful sense) and type-based dispatch based on object
definitions rather than a central table or equivalent, seem both
necessary and sufficient.  Everything else either merely makes it
easier, or makes not doing it harder.

Encapsulation is not necessary to structure code like this, but it's
handy to catch code violating this style.  Inheritance can help in
creating multiple similar types of objects, which can, used judiciously,
help construct sets of objects usable together.
Object identity is just plain not necessary.

> I've spent 10 years programming Smalltalk - there is no sense in which
> "everything is a subtype of everything else", everything is a subtype
> of Object.

There is a sense, though it isn't terribly useful: everything can
receive all selectors, they just get redirected to doesNotUnderstand: by
the run-time system.  Sure, the default implementation in Object halts
the program, but subclasses can handle it differently, and respond just
fine.

A slightly more useful sense would say that all classes who did override like
that would be subtypes of each other.

Not obeying the LSP, of course, but few people actually mean that when
they say subtype.

-- 
Aaron Denney
-><-