Hi.
> I don't actually agree with your patterns. In the second tracematch,
> the pattern you use is
>
> create (closeR|closeI) (readR|readI)
>
> I don't see why the sequence 'create closeR readI' should throw an
> exception (i.e. we create a reader around something, close the reader,
> and read from the something -- the same argument applies to the first
> tracematch).
I will check this. I was under the impression that when you close the
reader the underlying stream is automatically closed, too. But maybe I
am wrong.
> Also, I do think that we can capture all violations, no matter how
> stacked on top of each other. It does require a bit of fiddling
> though.... The approach might be as follows.
>
> - Define a static method invalidate(Object o) in the aspect (empty
> body).
> - Define a tracematch that, whenever it sees the creation of a reader
> or writer O on a subject I (either a stream or another reader/writer),
> followed by a call to (I.close() | this.invalidate(I)), calls
> this.invalidate(o).
> - Define a tracematch that, whenever it sees a call to
> this.invalidate(o) followed by o.read() or o.write(), throws an
> exception.
That sounds like a possible solution but brings us pretty much back to
where it all started with AspectJ ;-) When I mean "not doable" that
means for me "within the formalism", i.e. with one tracematch only.
Still, it would be interesting to find that out as it would capture a
very common pattern.
Eric
Received on Tue Oct 10 13:55:26 2006
This archive was generated by hypermail 2.1.8 : Tue Mar 06 2007 - 16:13:30 GMT