On Nov 8, 2003, at 4:03 PM, Phil Hargett wrote:

> Re fileout formats: I wouldn't want to implement such a beast with a 
> requirement that there be a new fileout format.  I would prefer the 
> set of declarations that describe an Aspect (or Traits, were the model 
> extended) still be representable in valid Smalltalk.  In fact, I've 
> implemented a draft of this model for things like Aspects, Advice, and 
> Introductions.  Each of them have several different subclasses for 
> more specific behavior.  Further, I designed this model with the idea 
> that an Aspect representing package Foo (let's say, FooAspect) is 
> actually represented in a class FooAspect that is a subclass of one of 
> the main Aspect subclasses that define aspect scoping (e.g., 
> PerVMAspect), and that an instance of a FooAspect is intended to 
> represent a "binding" of that Aspect in the current image.  That is, 
> all of the Pointcuts are resolved to specific CompiledMethods, etc.  
> Then, sending #invoke to the FooAspect instance will "install" the 
> Aspect in the image, and put it into force, modifying source code, 
> adding methods, adding instance variables, etc.

Well, ok, that's not technically a different file format, but it may as 
well be. A stock Squeak image isn't going to be able to file it in, 
since your aspect framework isn't present. Similarly, MC will have to 
be updated to parse the new types of chunks that create aspect-oriented 
programs.

> Re Introductions corresponding to MCs existing definitions: can MC 
> accomodate adding instance variables to other classes, and recognize 
> that that package (or PackageInfo) is the reason that instance 
> variable was added to another class?  In essence, I want to be able to 
> decorate classes outside of the package itself with new semantics.

Well, yes and no.

No, because right now a package can't include instance variables for a 
class not in the package. Yes, because that's a limitation of 
PackageInfo rather than Monticello.

Making variable definitions separate from class definitions is 
something I'd very much like to be able to do in Monticello, but the 
semantics aren't obvious in the case of instance variables added to 
classes external to the package. At least not to me. I'm very excited 
by Roel's work on Notifications and the opportunity it gives us to 
introduce a cleaner package model - one that will allow this sort of 
thing.

Colin