[plt-scheme] Re: Rationale of the object system?

Eli,

thanks for your extensive reply.

On Sunday 10 August 2008, Eli Barzilay wrote:
> On Aug 10, Michael Schuerig wrote:
> > If I have one regret, it is missing out on CLOS and the MOP. By
> > comparison, the PLT Scheme object system looks rather conventional
> > (at least from a Rubyist's point of view). Certainly the designers
> > of this object system knew CLOS and going the other way must have
> > been a conscious decision, I take it. If anyone remembers the tale,
> > I'd be curious to hear it.
>
> I don't know the tale, but having gone through implementing Swindle,
> I can tell why I wouldn't have chosen it as the OO model to use.  The
> CLOS-style OO is extremely slow by default, there is a lot of place
> for improvements (which most serious CLOS implementations do, and
> swindle also does, to some degree), but it's still an order of
> magnitude away from non-OO code.
[snip]

> Now, the fact that you have such a high price must come with some
> advantages -- in this case it's the extreme flexibility that you get
> because of the MOP.  You can pretty much change the face of the
> system completely with the given hooks and make it do anything you
> want. However, in practice I've seen almost no use of these
> capabilities.

It would be ideal if one only had to pay the performance price for the 
flexibility that is actually used in each instance. As you indicate, 
this at least involves a lot of low-level trickery, and may not be 
possible in general.

> So the bottom line so far is: you pay a heavy price; you get a lot
> for it; it's questionable if you actually need that kind of
> flexibility or if it's a good idea to use it.
>
> So far, it's still seems like a good thing to invest in, but the real
> killer is the side-effect that is inherent in defining new methods in
> CLOS.  The result of this is a system that is "too open" due to the
> fact that you can always change behaviors by adding and overriding
> methods -- there's always a foot around that you can accidently
> shoot.

I have to admit that this openness is part of what attracts me to 
CLOS-style (generic function-based) OO. As most of my dynamic language 
experience is with Ruby, I've come to appreciate and like the ability 
to add functionality to existing classes. Nonetheless, I'm aware of the 
utter non-modularity of it, and occassionally have been bitten.

> You might know the "thieves and bums use C++ and nice people 
> use CLOS" quote, which is (IMO) pretty misguided: if the only way to
> achieve a specific piece of functionality is by extending it in a way
> that is visible by all other code, then each such change can lead to
> potential debugging catastrophes.

No, I didn't know that one, but another one involving value and cost 
came to my mind while reading your earlier paragraphs.

> > I've found Swindle, of course, and I'm wondering whether it is
> > practically possible to use it instead of the "native" object
> > system.  Or maybe mix the two systems without too much pain.
>
> That depends.  Getting the two systems is easy -- all you need is
> require both and use a prefix to disambiguate.  But it's still
> question if this will be too much pain for you or not.  Another
> relevant question is whether you'll want to use existing code
> (usually GUI stuff) -- in that case it's probably better to avoid
> swindle.

That's as much as I expected. I feel a little like my anticipation for 
getting one kind of candy has been thwarted by receiving another kind, 
which may be just as sweet, but not what I was pining for.

Michael

-- 
Michael Schuerig
mailto:michael at schuerig.de
http://www.schuerig.de/michael/