[Shootout-list] Re: OO

[Aaron Denney]

On 2004-10-20, Isaac Gouy <igouy2@yahoo.com> wrote:
> --- Aaron Denney <wnoise@ofb.net> wrote:
>> >> Saying "the objects should support: interfaces, messaging,
>> >> mutation, and single inheritance" would make me a bit happier.
>
>> > 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.
>
> One object can always be distinguished from another.
> Is that sufficiently free of implementation detail? :-)

Sure.  I just don't see the point.  Why should it be part of the
language?  If you want that, add serial numbers to all your objects.

>> > Not sure what is meant by "interfaces" in this case
>> Not truly needed for OO,
>
> As-you-say not needed for OO.
> Unless you were to say encapsulation...

Encapsulation is different, but related in my mind.  One is exposing
what messages one can accept, the other is hiding what one can't.

>> >> 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".
>
> Nice try - for dynamic ones it's to a subtype of the type object.

*shrug*.  Not necessarily.  I can usually shove anything I want
in an array in a dynamic language and get it back out.  I might
not be able to use what I get out uniformly, but, whatever.

>> 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.
>
> Seems like the tests are intended for OO languages.
> Moreove it seems the tests are intended for class-based OO languages.
>
> "each program should be implemented in the same way"
> "the speed of method calls in OO languages"
> "method calls of a base and a derived class on an object of the derived
> class"

Well, yes.  I said it falls down for some OO languages the same way
it falls down for non-OO languages.  So I want to change it.

>> 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".
>
> What I'm saying is that it's easier to write a one-off fast solution
> when you don't have to make tradeoffs between the performance of
> different OO language features.

Yes, yes it is.  That's an advantage of languages without built-in
object systems that should be reported.

> C# has structs and it has objects - so we could choose to implement the
> object creation test using structs, and the method call test using
> functions. How silly.

Yep.  And it would hurt the LOC metric, but accurately reflect that you
can get a smidgen better speed out of C# by writing your own dispatch
routines.  (Or maybe you can't; maybe the builtin ones are better, being
handled at a lower level.   Wouldn't surprise me either way.)

But this discussion is getting old.  I'd rather go implement chain and
chainmsg.

-- 
Aaron Denney
-><-