Jim,
Thanks for the explanation. Making aspects project-specific is an interesting idea I never thought about before. Really nice!
Best, -Robert
As for the applications I have used
Jim Benson wrote:
Robert,
I've used it for simple tasks. Here's one way that I've used it as you've described:
I wrote a video-editing type of application which looked suspiciously like iMovie. I tried to emulate a typical desktop with dialog boxes, a tool bar and pull down menus.
Morphic has built in 'layering', that is, you can set the z-order of a morph by setting it's #morphicLayerNumber property. However, the PasteUpMorphs don't really honor that in the course of things when you add/remove morphs, so your system widgets tend to get written over and things are not pretty.
There are a couple of solutions to this. I could subclass PasteUpMorph into a "DesktopMorph" with all of it's attendant trappings. However, that type of implementation isn't very pretty as you have to reach further into the system code (and have a lot more system knowledge to do something which should be trivial) than necessary. I could be really careful about how I insert morphs onto my desktop, by substituting different addMorph type of calls for the normal ones (that's not in my nature ;-)
Or I could just let the machine do the work. Really, I only wanted to transform a couple of PasteUpMethods methods such as (conceptual code):
PasteUpMorph>>addMorph: aMorph self addMorphInLayer: aMorph.
to make them honor the morphic layering. Of course with your SAspect code this was easy. When I entered a video project, I would tell the project to install the appropriate aspect to make the PasteUpMorph morph (world) behave the way I wanted. When I left the project, I removed the aspect, which returned the image to stock behavior. This is all part of the MethodWrappers concept. This is all second nature to me, having patched many interrupt traps before.
In the Smalltalk world this is a very subtle nuance (like a 16 ton weight). I've redefined a methods behavior, not by overriding it or recompiling it as one would traditionally do, but by shaping it after it has been defined. This is also a different concept than having 'pluggable' behaviors, where one would store a method or block context for execution into an ivar and then substitute a different block of code into that ivar.
Of course, this is crucial to the modules code. I've been following the modules discussion here, but here's my fundamental concern: How do I end up not programming on quicksand? From what I understand so far, the modules solution is about keeping different chunks of code and data in a seperate space that you can 'swap' in. I can see how that works if the module is independent and does not change the 'base' image code. Where I get lost at is how all the modules interact when they fly back into the image, and start changing that base code, potentially over writing each others changes. If you don't have a stable base, and some protocol saying how you can attach changes onto that base, it turns to quicksand real quick.
I haven't looked very deeply into the weaving parts yet, though I think I have a good application for it in the area of autonomous characters. This is obviously the interesting area of your work. What type of applications have you been using it for?
Jim
Thanks, Jim.
Have you tried to use AspectS for other tasks than debugging?
With AspectS you can change the behavior of the system not only at the level of classes, but also from the point of view of a subset of specific instances, either senders or receivers of a certain message, or both...
Best, -Robert