Re: [abc-users] Behaviour of release(..) method in relational aspects

Thanks for the reply. It gave me a good insight over the mechanics of
relational aspects and how tracematches handle it nicely.

I admit that this may not be straightforward to see. Are you going to
be at the AOSD conference this year? I will be giving a talk about
relational aspects there.

I will not be there unfortunately. I will be busy during that time
revising instead!

Eric Bodden wrote:
>> How does the release(..) method work? Does it look up a table of
>> associations and revoke the specific association according to the vector
>> of objects (if it exists)?
>>
>
> No. You should read the paper...
>
> We generate a tracematch for each relational advice. This tracematch
> *roughly* has this shape:
>
> tracematch(X x, Y y) {
> sym after returning associate .... //binds x,y
> sym after returning release .... //binds x,y
> sym after returning action .... //binds x,y
>
> associate action { .. }
> }
>
> If you understood tracematches then you should see that quite
> naturally, in the above tracematch a call to release will reset all
> partial matches for this tracematch, because it is a "skip" symbol.
> There's no special implementation of release. It's all done
> automatically by the tracematch machinery. That's the beauty of the
> approach.
>
>
>> For example, I have the following code, where RA is some relational aspect:
>>
>> Object o1 = new Object();
>> Object o2= new Object();
>> RA.associate(o1, o2); //o1 and o2 are now associated through RA
>> RA.release(o2, o1); // Compiles fine and no run time errors as well
>>
>> It is the RA.release(o2, o1) call that is of interest. This call
>> obviously does not have any effect on the association between o1 and o2,
>> but my question is why is it allowed to run freely on the main program?
>> I would have thought an error or some sort of warning would be thrown,
>> citing the non-existence of the association (o2, o1).
>>
>
> No, by design this is not the case. If you look at the above
> tracematch definition, then you see that the release-call in your
> example does not at all update the tracematch automaton state.
> Therefore it would be very hard to give an error in such situations.
> In fact you would need a second tracematch just for that, which is
> hardly worth the price.
>
>
>> I am just asking this out of curiosity.
>>
>
>
> Eric
>
>
Received on Thu Mar 06 2008 - 16:46:36 GMT