[Shootout-list] Re: OO (was Re: process creation & message passing)
Aaron Denney
wnoise@ofb.net
Wed, 20 Oct 2004 19:36:58 +0000 (UTC)
On 2004-10-20, Isaac Gouy <igouy2@yahoo.com> wrote:
>> Saying "the objects should support: interfaces, messaging, mutation,
>> and single inheritance" would make me a bit happier.
>
> Why would a multiple inheritance language be less OO?
It wouldn't, but I don't consider multiple inheritance necessary, only
single.
> What happened to object identity?
Honestly? I'm never sure what's meant by it. Any definition that I
hear seems more like an implementation detail than semantics.
> Not sure what is meant by "interfaces" in this case
A way to create a type of "responds to these types of messages /
implements these methods". e.g. java's interfaces, objective-c's
protocols, C++'s abstract base classes, o'caml's class interfaces (those
lists of methods in angle-brackets), etc. Not truly needed for OO, but
it's something that I found incredibly useful. It's not something
we would want as a requirement, as excluding Smalltalk seems like a
really bad idea. It was just something I tossed out as one of the axes
along which OO breaks down.
Actually even single inheritance throws out some pretty standard
prototype based languages that I'd think you'd want to include.
> One persons "messaging" is another persons function call ;-)
Well, yeah, but it's a question of where the dispatch happens, and
making that distinction is useful, I think.
>> Compare with arrays, where it is commonly understood to be an
>> optimized map from a continuous subset (usually [0,n[) of the
>> integers to one arbitrary type.
>
> That would only be true of statically checked languages.
Nope. For dynamic ones it's to the type "object".
>> > Creating OO in a non-OO language should show up in the LOC metric -
>> > if it doesn't it is a good indicator that objects were not so hard
>> > in the specific language.
>>
>> Quite true.
>
> I disagree - the objinst & methcall tests weren't designed to test
> that a language was OO, but to measure performance.
And they do! But it's not all that gets measured.
I thought the idea of the shootout was "how easy (LOC), and how
performant (CPU & MEM) is it to use these techniques in these
languages". OO style is a technique and different levels of language
support make it easier or harder.
What we don't want is any implementation of the test to drift too
far away from this OO style. One easy way is to exclude any non-OO
language. I don't like it because that's saying "You can't do OO
in this language" rather than "it's extremely hard to do OO in this
language".
Another is to look at the submissions, and say "that's not sufficiently
OO". But we should be able to back-up why we think it's not, and
suggest to submitters what they can do to make it more OO.
--
Aaron Denney
-><-