[MCZ] and adding related files

Phil Hargett hargettp at mindspring.com
Sat Nov 8 22:35:40 UTC 2003


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