[aosd-discuss] non-intrusive modification of existing code

[Johan Ovlinger]

Eric Eide wrote:
> The same sort of concerns were expressed about OOP languages when OO was new:
> for example, that if programmers can create subclasses and override methods, it
> becomes easier for programmers to screw things up and break modularity in new
> and novel ways.
> 

Well, there are a couple of minor but pertinent differences:

1) some languages (notably C++) require methods to be exported for 
overriding; in effect declaring them a join-point.  In Java the defaults 
are reversed, but the same capabilities exist.

2) The object must be instantiated at the more specific type in order to 
see the overriding behavior, while aspects are applied to the program 
w/o modification. Dynamic dispatch, the abstract factory pattern, and 
module languages such as Jiazzi that late-bind class names  muddy the 
waters a bit, but you still need to try pretty hard before you get the 
same level of parametrization of the base program as AOP gives you for free.

> And it's true, in theory.  In practice, however, OO programmers have figured
> out how not to screw things up too badly, at least most of the time.  People
> interested in AOP/AOSD --- you and I included :-) --- are now figuring out the
> "best practices" for AO.

True, but only by keeping to the well-lit part of the street and 
avoiding the murky alleyways. For example, fields in Java can be 
overridden, and the semantics are well defined, but I tend to avoid that 
like the plague. But then you wonder why the murky features are there at 
all. Programmers do identify offending parts of a language, and develop 
idioms to avoid them, but the fact that they are still there costs you 
in that it makes it that much harder to analyse programs.

Rules of thumb such as "always call proceed in around methods" and 
"create stub methods specifically for attaching advice to" are probably 
  very helpful to the programmer, but completely useless to the compiler 
and other programming tools, as they have to take into account what 
could be done, rather than what should be.