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