[MCZ] and adding related files

ducasse ducasse at iam.unibe.ch
Sun Nov 9 08:03:56 UTC 2003


Hi phil

if we remove the aspect semantics, you have a code model like Ginsu 
that covers packages, classes, methods....like monticello.
With Ginsu the loading of a package was installing declarative elements 
that are objects that the browsers uses in Class, CompiledMethods and 
so on....

So the idea is the same.

Stef

On Samedi, nov 8, 2003, at 23:50 Europe/Zurich, Phil Hargett wrote:

> 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
>>>
>>>
>>
>>
>
>




More information about the Squeak-dev mailing list