Re: [abc-users] Tracematch matching semantics

Hi Jon,

I believe your original tracematch should be able to distinguish two
different objects in a trace. This is because of the object (Editor) is
bound on the pointcut as well as the formals of the tracematch.

I hope I'm not wrong again (I'll have to be corrected again if that were
to be the case :-)), it's been some time since I last used tracematches,
but I do find them to be an excellent means of describing what would
otherwise be very cumbersome expressions in terms of pointcuts in
traditional aspects.

- Alan

Jon Oldevik wrote:
> Hi,
> Thanks everyone for prompt and informative answers.
>
> I have another question concerning the tracematch semantics:
>
> In the OOPSLA'05 paper it is specified that trace matches are
> sensitive to instances if the same variable is bound several times in
> the same tracematch, its value (object equality) must be identical in
> order to make a match.
>
> Is it also possible to create a tracematch that is capable of
> distinguishing two different objects in a trace, lets say to capture a
> trace where a sequence of messages is sent to object a0:A followed by
> a sequence of messages sent to a1:A, where a0 != a1?
>
> Regards,
> Jon Oldevik
>
>
> On Thu, 11 Sep 2008 03:18:02 -0700, Pavel Avgustinov
> <pavel_at_comlab.ox.ac.uk> wrote:
>
>> Note: Somehow this message remained in my unbox unsent, and I see
>> there have been some replies in the meantime.. sorry for the delay,
>> and any repeated information.
>>
>> ---------------------
>>
>> Hi Jon,
>>
>> Yes, this is indeed working as designed. The tracematch pattern is
>> matched against *all suffixes* of the program trace. Thus, after the
>> second 'save' event, the last two save events trigger a match, and
>> after the third 'save' event, the second and the third events trigger
>> a match.
>>
>> The formal semantics of the matching behaviour is laid out in our
>> OOPSLA'05 paper
>> (http://abc.comlab.ox.ac.uk/documents/re21-allan.pdf). Note that
>> there is an example there that is superficially similar to yours: We
>> define an "autosave tracematch" that automatically saves a document
>> every 5 actions after the last save. There, the pattern is indeed
>> just "action [5]" (where yours is "save [2]), however, it would not
>> trigger after every single action after the 5th. The reason is in the
>> body of the tracematch: That calls "Application.autosave()", which
>> matches one of the declared tracematch symbols which isn't referenced
>> in the pattern. This event effectively resets the matching state,
>> since no suffix will match the pattern until another five action
>> events occur.
>>
>> Hope this helps, do let me know if I can clarify further.
>>
>> - P
>>
>> Jon Oldevik wrote:
>>> Hi,
>>> I have a question about the matching semantics that tracematch
>>> supports.
>>>
>>> given a really a tracematch, e.g. the simple one given below, which
>>> is matching two subsequent calls to save: When two 'save' are
>>> detected, the tracematch gives a match. However, when a third 'save'
>>> is detected, a new match is given (rather than waiting for a fourth).
>>>
>>> Is this the intended semantics of tracematches?
>>>
>>> public aspect MatchTwoSaves {
>>> pointcut save(Editor e): target(e) && call (* Editor.save(..))
>>>
>>> tracematch (Editor e) {
>>> sym save after returning: save(e);
>>> save save {
>>> // we got a save+save match, now do something with it
>>> }
>>> }
>>> }
>>>
>>> Best regards,
>>> Jon Oldevik
>>>
>>
>>
>>
>
>
>
Received on Sat Sep 13 2008 - 10:44:44 BST