|
From: Craig L. <cr...@ne...> - 2004-04-09 04:58:11
|
Hi Andreas-- > > The current Squat implementation checks if the receiver's class is > > a special "proxy" class (currently called "Other"), which is in the > > special objects array. If it is, it kicks the send back to image, > > using the same mechanism as for >>doesNotUnderstand:, so that the > > message may be forwarded by the proxy. > > I'm missing something here - if it uses the same mechanism why would > we need to change the lookup? Heh; by "same mechanism" I mean I use >>createActualMessageTo: and the remapping stuff, similar to the message-not-understood support later on in Interpreter>>lookupMethodInClass:. I didn't literally mean the message-not-understood behavior itself. Hopefully you've seen my version of >>lookupMethodInClass:, to see what I mean. > Put differently, wouldn't it have the same effect if you just make > Other a ProtoObject? I think it's useful that (with this VM support) Other can be anywhere in the class hierarchy. In particular, it's impervious to whatever junk ends up in any potential superclasses (*especially* Object or ProtoObject ;). Also, I think having multiple class hierarchy roots is unnecessary, but let's please not rehash that in this thread. > > The VM is the thing that does the activation marking. I'm using that > > mark to tell when any method from a method dictionary has been run; > > it's useful for, e.g., calculating which classes can be swapped out > > of an image at some point in time. (There are also primitives for > > reading and clearing the marks.) > > I'm missing something here too (guess I'll have to check the code). > This sounds as if a method dictionary with an extra iVar or so would > achieve the same effect at the same cost. Here again, in addition to cost I'm also concerned with security. I'd like to use a mechanism for this which is less exposed to interference from the image. I don't want this information to be reachable from, e.g., >>instVarAt:put:. I'd prefer that people have to go a bit more (and more informed) effort to manipulate the marks, and be less likely to change them inappropriately by accident. Basically, I think this is properly considered "special VM knowledge" that happens to be attached to these objects, but shouldn't be directly visible in the normal ways to object memory inhabitants. thanks again, -C -- Craig Latta improvisational musical informaticist cr...@ne... www.netjam.org [|] Proceed for Truth! |