on Tue, 28 Jun 1994 22:31:23 -0400 email@example.com 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).
I don't think that Self should allow arbitrary code to be executed during message lookup.
I explored the current behaviour when I was trying to discover if Self has the necessary facilities to enable protection of resources from each other... (it doesn't.)
I came to the conclusion that:
a) it has horrible effects on code and lookup caches
b) it does what you can do with message (re)sending already, i.e. there is little advantage in doing it.
c) you could change Self by specifying that the message lookup searches all the data parents first, *then* expands the code slots *if* the message hasn't already been satisfied. That way, the code caches can be built. However, doing it is then dangerously close to the prioritised parent slots that were tried out and abandoned in Self.
This isn't life in the fast lane, it's life in the oncoming traffic. - Terry Pratchett