[aosd-discuss] non-intrusive modification of existing code
johan at ccs.neu.edu
Sat Feb 28 13:49:28 EST 2004
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.
More information about the discuss