[PRL] legacy code and AOP

[Karl Lieberherr]

There is a third view to AOP:
(3) Evolution by addition rather than modification. I like to summarize
this as: Talk only to your friends who share your concerns. Of course it
is related to (2): the "other" modularity mechanism is used to program a
new concern as a separate entity.

There is more activity in the C space. The industry track at AOSD 2005
has an invited talk: 

Invited Talk: AOP with C++  
Olaf Spinczyk

A note to Matthias: the messier a program, the harder it is to write
aspects because your selector expressions will be messy. I consider this
a positive property of aspects: They promote good program structuring. 
 
-- Karl

-----Original Message-----
From: prl-bounces at lists.ccs.neu.edu
[mailto:prl-bounces at lists.ccs.neu.edu] On Behalf Of Shriram
Krishnamurthi
Sent: Wednesday, February 09, 2005 10:59 AM
To: Matthias Felleisen
Cc: 'PRL mailing list'
Subject: [PRL] legacy code and AOP

Matthias Felleisen wrote:

> If this is true and AOP is also about change huge code bases to do the

> right thing _after the fact_

There are two views of AOP: (1) as a refactoring device, and (2) as
("just") another modularity mechanism that should be integrated into
all aspects of the development cycle.  I used to take view (1).
Gregor has persuasively convinced me that at least for him, (2) is the
right way to think about AOP, and (1) doesn't register.  So there are
many in "the AOP community" who would disagree with the claim I've
quoted above.

[Then again, I found out yesterday that there are purported leaders of
the AOP community who don't even know that aspects can interfere with
one another, so it's hard to tell what, if anything, "the community"
even knows as a whole.]

> has anyone thought of developing an AOP system for C

Yes.  I believe Gregor and Yvonne Coady, in FSE 2001, talked about
AspectC in the context of OS refactoring.  Julia Lawall's work is not
quite an aspect system for C, but has a DSL component that compiles
into C that performs aspect-like maintenance.

> Is CS really guilty of always solving engineering problems that
> nobody has created yet?

As Tuco says in The Good, the Bad, and the Ugly: "When you need to
shoot, shoot -- don't talk!" (-:

Shriram

_______________________________________________
PRL mailing list
PRL at lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/prl