Yes, Traits and Aspects don't have to be mutually exclusive; they both 
have their place as techniques. :)

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.

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.

On Nov 8, 2003, at 6:30 PM, Colin Putney wrote:

>
> On Nov 8, 2003, at 2:35 PM, Phil Hargett wrote:
>
>> I'm completely interested in that kind of redesign of MC; that is, 
>> specifically, adding more complex types of info to a Package.  In 
>> fact, I recently wrote some code for myself that took it's 
>> inspiration partly from PackageInfo and partly from Aspect-Oriented 
>> Programming.
>>
>> The locus of MC is the package, which contains a set of classes and 
>> methods (e.g., extensions).  In my model, an Aspect was the locus, 
>> and it could contain several more things than just classes and 
>> methods:
>>
>> 	--Introductions: new Classes, new methods in existing classes, new 
>> instance variables in existing classes, new class variables in 
>> existing classes, and new global variables (e.g. entries in 
>> SystemDictionary instance Smalltalk)
>> 	--Pointcuts: named sets of Class / selector pairs, used as locators 
>> for specific methods
>> 	--Advice: associated with one of the named pointcuts, an Advice 
>> contains a block of code that will be inserted into the source of the 
>> methods identified by the pointcut at specific joinpoints: e.g., 
>> before the body of the method, after the body of the method, or 
>> around ("instead") of the method
>> 	--Other aspects: allows one to aggregate and reuse multiple aspects
>
> I'm interested in this sort of alternative code model as well, more 
> with regard to Traits than Aspects, but in either case I don't think 
> it would be too difficult to add. Your introductions correpond to MC's 
> existing definitions, and all you'd need is new definition classes for 
> Pointcuts and Advice.
>
> The only real stumbling block is the mcz file format, which is 
> designed to make the code accessible to non-Monticello-users. Since 
> our current model of a program is closely related to the Squeak 
> runtime, it's isomorphic to Squeak fileouts, and mcz contains a normal 
> fileout with the package's source code. To deal with Traits or 
> Aspects, we'd need a new fileout format that could go in the mcz 
> archive.
>
> This relates to the recent discussion of alternate Metaclass 
> implementations, (sorry, can't remember whom to credit), which I found 
> facinating. My intuition says that for every implementation of 
> Metaclass, there exists a way to declaratively model programs written 
> for it. As long as that's the case, we can use Monticello to version 
> them.
>
> Right now, Monticello can only work with ANSI Smalltalk (more or less) 
> programs, but there's no reason we couldn't adapt it for Traits, 
> Aspects, Mixins, Prototypes or whatever else people find interesting.
>
> Colin
>
>