[Fwd: Re: [aosd-discuss] Non academic ideas on AOSD]

[Juri Memmert]

Am Die, 2002-10-15 um 20.04 schrieb Radek Jedrasiak:

Hi Radek,

> Many times people argue about the lack of control over the
> places aspects can be applied to in their already created code.
> I share this point of view. It gives me those horror of not
> knowing what some certain aspect will turn my ready code into.
> This is for sure not a problem with the examples provided. But
> even today without aspects weaved into code, real world systems
> can heavily suffer from some uncontrolled changed code. Nothing
> new to you I guess.
> 
> So how about allowing the developer to define the points aspects
> can be applied to ? (People fear most what they can't control)
> Instead of allowing to inject code at *any* defined joint-point in
> the language, we could extend the languages (I know this could be problem)
> to allow them to define "allowed" joint-points in source-code.
> I know this is a quite big restriction, but I think it is one which
> would make the concept more easily accepted.

May I point you at the thread "New-guy-type questions" from a few days /
weeks back?
It does address some of this.

One thing you might want to consider is that predefining a set of
allowed join-points would limit the evolvability of the code to these
predefined join-points.

One of the advantages of AOSD approaches is that they can easily react
to non-anticipated changes. Limiting the approach, in your case,
severely limiting the approach (as you correctly say), will also limit
the ability to react to non-anticipated changes.

It is true that limiting the access to the code will make the developers
happy, but the question: "What will an aspect do to my code?" remains a
security question, a question for your build manager and is not really a
coder-question.

As I wrote before:
> Give me a byte-code manipulation library and I will circumvent any
> approach you might take. And no matter what kind of mechanism you
> might use for the "Don't AOP Me"... as long as the weaver can
> recognize it, I can circumvent it.

And if you choose to go for custom JVMs, you're hosed anyway (do I need
to elaborate this or is that obvious?).

The next question is what to do with "legacy code"? I.e. code that was
not developed with AOP in mind? It will not be modified for AOP, so
access to that code would be unlimited. And the probability that you'll
deal with non-AOP code will remain high for a long time.


> Well, there would be still the need for "predefined" joint points
> like "before-method" or "after-method" as no one would want to
> place them by hand I guess (I guess it would be hard but not impossible
> to decide which joint points should be predefined) ....
> 
> I'm quite aware that this is a *very* restricting usage of the
> aspect idea, but I also think that making the available joint points
> part of the public interface of a class would be a good idea.

It is a nice idea, but the points listed above (and those in the
mentioned thread) give me pause to consider such an alteration.


	Juri