[aosd-discuss] Hyper/J vs Apect-J

Thu Sep 12 09:26:26 EDT 2002

Hello awais,
good point, but this scenario would fit in one of the two cases:

1. accicdential advice, where a strict order and a "need to know about"
relation is not existent, (no intended influencing side effects) (for this
case dominates and subordinates would be IMHO sufficent)

2. the advice could be rewritten to advice not the original advice,
 but the advice for the advice, and so on.

So would you think that 2 is not practical, or that we need some new more
efficent 
construct?

regards
   Arno

-----Original Message-----
From: Awais Rashid
To: Arno.Schmidmeier at sirius-eos.com; elrad at iit.edu
Cc: memmert at jpmdesign.de; discuss at aosd.net
Sent: 9/12/02 5:10 PM
Subject: RE: [aosd-discuss] Hyper/J vs Apect-J

-----Original Message-----
From: discuss-admin at aosd.net [mailto:discuss-admin at aosd.net]On Behalf Of
Arno.Schmidmeier at sirius-eos.com
Sent: 11 September 2002 09:44
To: marash at comp.lancs.ac.uk; elrad at iit.edu
Cc: memmert at jpmdesign.de; discuss at aosd.net
Subject: RE: [aosd-discuss] Hyper/J vs Apect-J

 Hello Tzilla, 
hello Awais, 
hello everybody else, 

Based on my experinece with aspectJ in comercial projects, 
ordering the aspects is a real problem. This lead to my submission of
the 
"construct of the opposite of dominates". (Let's call it subordinates
for now) 
Dominates and subordinates are IMHO more than sufficent, for simple
ordering 
of the execution of advices form nearly independent aspect. 
in other words for aspects who "accidential" advice the same pointcut. 

e.g. I have aspects for logging, caching, and billing: 
billing and logging can be executed in any order, however caching 
must be always executed after logging and billing or otherwise round. 
These simple orders can be expressed quite simply. 

However I find many places, where I want to wrap an around advice 
around an around advice. Because aspectJ does not support (hopefully
jet) 
a pointcut for advices, I have to hack this functionality with
dominates/subordinates. 
These are the places in the code, where I got plenty of tangling
pointcuts, 
tangling dominates-statement etc. 

With such a construct the composition from A, around B, on some places
in C 
could be done easier, and much more easier to maintain. 
Currently A and B depend from the same pointcut definition (pcd) of C. 
With such a mechanism A would then only depend from B where B would only
depend 
from the pcd of C. 

Much easier to maintain, expecially if asbstract aspects are involved. 

Awais, would such a mechanism also solve your interaction scenarious? 

Not necessarily. I think this would solve the problem of having aspects
of aspects. Interactions could still exist with multiple aspects
defining poitcuts based on the same advice!

Awais.

 Arno 

-----Original Message----- 
From: M. Awais Rashid 
To: Tzilla Elrad 
Cc: memmert at jpmdesign.de; discuss at aosd.net 
Sent: 9/11/02 10:02 AM 
Subject: Re: [aosd-discuss] Hyper/J vs Apect-J 

Tzilla, 

> >Also, I do not agree that in the AspectJ model aspects are not 
supposed 
> >to 
> >talk to each other. In most applications (in my experience) they have

to, 
> >directly or 
> >indirectly (by influencing the same joinpoint). However, the latter 
leaves 
> >much to be desired of the interaction resolution model in 
> >AspectJ. Dominates and simple advice ordering does not really cut it 
when 
> >you have a few largish aspects in your application. 
> > 
> >Awais. 
> 
> I would like to refer to one point only, so for the sake of simplcity 
I 
> deleted the rest of the corospondences. 
> 
> MIR:  Multi-Interacion-Resolution 
> 
> The issue is when, how, by whom and on what visability rules 
interaction 
> resolutions could be made. It is true that in AspectJ we have the 
"base" 
> and "aspects" that are reated differently where as in Hyper/J any two 
pieces 
> os software can be combind with each other. 
> Both hyper/j (?) and AspectJ are limited to interaction of TWO pieces 
of 
> software at a time. This makes interaction resolution based on a group

of 
> software pieces complicated.  many times there is no simple 
serialization 
>  sequence of pairs-interactions that can simulate this 
> Multi-Interacion-Resolution 
> 
> How would you simulate a general MIR- Multi-Interacion-Resolution in 
AspectJ? 
> Hyper/j? 

I don't think there is any easy way to do this in AspectJ. AspectJ 
allows 
one to express logical combinations of aspects in the dominates clause: 

Aspect A dominates (B || C) 
Aspect D dominates (E && F) 

etc. 

However, the above example further demonstrates how complex interaction 
resolution can become in an application with just a few aspects let 
alone 
with tens or hundred of them. One of the main problems with the above 
model is that it specifies the interaction with reference to a 
"base" aspect. As a result if aspects B and C change and now B dominates

A 
and C you need to change the two aspect definitions. Of course, one 
could 
argue that it is just the dominates clause that needs change. However, 
it 
is quite easy for a programmer to forget this which can lead to 
undesirable behaviour in the program. 

Personally, I feel that interactions cut across an AO system and should 
be 
specified as an "aspect" themselves. However, I don't mean to say "as an

aspect in AspectJ as it stands today". We need a clearer interaction 
resolution model not just for AspectJ but for AOP techniques in 
general. 

Kind regards, 

Awais. 

> 
> -Tzilla 
> 
> 
> 
> 
> 
> Dr. Tzilla Elrad 
> Research Professor 
> Department of Computer Science 
> Illinois Institute of Technology 
> (312) 567-5142 
> http://www.iit.edu/~elrad <http://www.iit.edu/~elrad>  
> 
> 
> _________________________________________________ 
> AOSD discuss mailing list    -   discuss at aosd.net 
> To be removed send mail to discuss-admin at aosd.net 
> or visit http://aosd.net <http://aosd.net>  
> 

_________________________________________________ 
AOSD discuss mailing list    -   discuss at aosd.net 
To be removed send mail to discuss-admin at aosd.net 
or visit http://aosd.net <http://aosd.net>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://server2.hostvalu.com/pipermail/discuss_aosd.net/attachments/20020912/fc84574c/attachment.htm