[plt-scheme] Rationale of the object system?

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.  (In comparison, I think that the PLT
class system is very close to non-OO code.  But it's hard to come up
with numbers, since in both cases you'd me mixing things up.)  In
addition, such optimizations involve a lot of low-level hacking in the
form of dynamic code generation and such, for example -- see how CLOS
uses macros to define method combinations.

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.
In CLOS there's the standard example of persistent objects and very
little beyond that.  To make this point even stronger, with a language
as flexible as PLT Scheme, where modules play nicely with macros, you
can easily get such different behavior using macros.  (The obvious
question is which way is easier, I have no answer to that.)  As a
corollary, too much MOP-level games are close in spirit to too much
macro-level games: you end up with a language that is very different
from the original, which diminishes it's general usefulness (since the
threshold of using it is much higher).

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.
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.


> 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.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!