consistency in Self

Michael Grant Wilson mcq at
Wed Jun 29 15:07:41 UTC 1994

on Tue, 28 Jun 1994 22:31:23 -0400 <dbc at> wrote: 
> Further, consider the implications of allowing arbitrary code to be
> executed as part of message lookup. With the right kinds of mirrors
> and assignable parent slots, you can probably completely re-write the
> mechanics of message lookup (for all practical purposes).  This isn't
> a bad thing per se, but then you must ask: why have message lookup at
> all?  Why not just get rid of the implicit inheritance mechanism and
> make everyone forward messages on themselves (explicitly (using the
> Tready of Orlando verbiage here))?
I'm not claiming this is the correct viewpoint, but it should be noted
that the CLOS people seem to think that they are getting a lot of value
out of redefinable method lookup. It doesn't negate the value of the 
"standard" lookup mechanism, just extends it to cover some exceptional
circumstances which you couldn't easily model otherwise. 

> Yes, but if it becomes commonplace, it will show up everywhere, and
> optimization will go out the window.  In our graphics system here at
> Brown, we cache a lot of stuff (like Self does), in the expectation
> that we'll use it again. As it turns out, most of the problems we're
> trying to do these days have so much changing stuff, the caches are
> never used more than once: we spend more time keeping track of the
> caches than we could gain by using them.  Needless to say, we turned
> off large portions of the caching ability.
Right. Of course, my view is that it is unlikely that the use of the 
mechanism would become 'commonplace'. It really is a meta-level feature, 
and I expect you would only find it in a small number of system level
places (examples: lazy method mutation, or dynamic link library interfacing).


More information about the Self-interest mailing list