BTW: I don't know if my prior message explains *why* I would want all 
of this in an Aspect (where an Aspect is like PackageInfo, but 
capturing much more semantic detail).  I think I presumed everyone on 
the list has some familiarity with the basics of AOP and what it is, 
which wasn't wise on my part.

When I write code and package it for distribution, I want to be able to 
write some code and say "this code requires X global variable 
initialized to Y value, Z method in class M, variable N in class O, and 
new code P to be appended  to the end of every method in a set I've 
specified."

In my AOP model, the X global initialized to Y value would be captured 
as a GlobalIntroduction, the Z method in class M would be a 
MethodIntroduction, variable N in class O a ClassVariableIntroduction, 
and code P would be "after" advice (e.g, AfterAdvice) on a specific 
Pointcut that I would also include in the Aspect.

An Aspect allows me to bundle all of these rich semantic changes into a 
single set of changes.

On Nov 8, 2003, at 5: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
>
> With this approach, I have more complex options for inserting code 
> into an image: rather than just replace a method (or class) in toto, I 
> can modify the source code of those objects directly and with 
> precision--without replacing the existing source entirely.  Plus, by 
> focusing on modifying source code (or class definitions), the run-time 
> overhead of applying Aspect-Oriented Programming techniques is either 
> minimized or eliminated.  Although I haven't added all types of 
> Aspects, having different kinds (e.g., an aspect which is instantiated 
> once for the whole VM, once per affected class, once per affected 
> instance, once per affected process/call flow) would allow one to 
> insert aspects into the architecture of the system (e.g., new instance 
> / class / process variables to hold relevant aspect instances), which 
> I believe is the proper way to do AOP.  Much of what AOP can do is 
> provide a short hand for certain architectural patterns of objects and 
> their relationships, without requiring one to manually code every 
> application of those patterns.
>
> A few other things I liked about this approach: because "installing" 
> an Aspect directly modifies source code and class definitions, there 
> is no need to worry about improper use of MethodWrappers (the core of 
> how the AspectS approach works) corrupting the image.  Further, most 
> of the changes caused by "installing" an aspect can actually be backed 
> out (e.g., if you introduced an instance variable on installation, 
> just remove on deinstallation).  The proper role of AOP, I believe, is 
> in helping us create better, more well-structured source code *before* 
> compilation, not adding complex runtime architecture that's harder to 
> understand or troubleshoot.
>
> In fact, I hoped that if I ever finish this code that these kinds of 
> Aspects could be woven tighter into ChangeSet code: whereas now we 
> create ChangeSets, I'd love to see our changes create "Aspects," which 
> more precisely capture the types of changes we actually.  The act of 
> "installing" an Aspect would generate a ChangeSet, and directly modify 
> the image.  To do that most effectively would require that even our 
> tools change, so that we rarely browse classes or methods directly, 
> but instead browse the view onto the image through our current 
> "aspect."  These tools would not allow us to modify a method directly, 
> per se, but would allow us to describe some "advice" that we'd like to 
> include in the aspect: for example, a method could be completely 
> replaced in the aspect by using an "around" advice on that specific 
> method, 'causing the code in the aspect to execute for that method in 
> place of the original code.  Finally, because Aspects (as 
> sophisticated ChangeSets) could include other Aspects, then one could 
> precisely capture the dependencies and prerequisites between what are 
> today simple packages or instances of PackageInfo.
>
> Anyway, that was an idea that I had in mind.  I can't advocate that 
> this is completely the right way to go, as the problem with things 
> like this is it's a little dependent on one's work style.  AOP-style 
> programming may not fit within every programmer's style of 
> development, even if it may be something they do unconsciously.  AOP 
> happens to be a technique that I believe adds value, when used 
> properly.  Again, this is an idea; perhaps there may be tidbits 
> expressed here that others find useful.
>
> :)
>
> On Nov 8, 2003, at 5:00 PM, Avi Bryant wrote:
>
>>
>> On Nov 8, 2003, at 10:01 AM, Colin Putney wrote:
>>
>>> I agree; SAR is the way to go for this sort of thing.
>>>
>>> Mcz is a strictly declarative format, containing only snapshots and 
>>> version info. The fact that it's also a zip file is an 
>>> implementation detail; Monticello will ignore anything it doesn't 
>>> expect to find.
>>
>> The question would be whether you wanted these extra files to be 
>> versioned along with the code.  There's no reason Monticello's notion 
>> of package/snapshot couldn't be extended to include external files - 
>> indeed, I'd always planned that MCPackage would allow various 
>> declaration-providing services to register with it, with PackageInfo 
>> (providing classes and methods) being just one of these.  Colin's 
>> right that for now SAR is the only way to do what you need, but I'm 
>> curious if there's any interest in that kind of redesign of MC.
>>
>> Avi
>>
>>
>
>