on Tue, 28 Jun 1994 22:31:23 -0400 dbc@cs.brown.edu 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).

McQ.