[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cme-users] Query Language NOT operator
|
On Wed, 2004-07-28 at 19:30, Peri Tarr wrote:
Hi Peri,
> Sorry for not responding sooner--for some reason, this message missed
> me (or perhaps I accidentally deleted it during a mass killing of
> reams of spam :-)), so Harold just brought it to my attention.
no problem.
> >I just stumbled about a small problem that I do not seem to be able
> to
> >handle.
> >
> >I would like to express:
> >
> >All calls to the method execute in the class Cosmos that are only
> from
> >within a class that extends Concern.
>
> Let me be sure I'm clear on this: you want all calls to
> Cosmos.execute(..) such that the calls occur in subclasses of class
> Concern? (I'm going to assume this is what you mean subsequently, but
> if I'm wrong, probably everything else I tell you is wrong :-), so let
> me know what you actually meant.)
Yes. Correct.
> >I can do
> >[1] "call( * Cosmos.execute(..))"
> >and get all the calls.
> >
> >I can also do
> >[2] "relationship extends(class * ,class Concern)"
> >and get all the classes
> >
> >Now, I want to combine both and that does not work out in any form.
> >
> >The best I could come up with was:
> >
> >[3] "call( * Cosmos.execute(..)) && within(sourceof(relationship
> >extends(class * ,class Concern)))"
> >
> >Unfortunately, this gives me a syntax error ("Syntax Error in
> query.
> >Reason: Syntax Error in query") which is less than enlightening to
> me.
>
> Interesting. That's the query I would have suggested.
Yeah, isn't it?
> Okay, I've looked into this, and it's a problem with our query
> parser--it's treating "within" as an identifier instead of as a
> reserved word. (This traces back to a problem with our parser
> generator, which I'm in the process of replacing.) Would you do me a
> favor and raise it as a bug, please?
Right away. Done. Bug #71046
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=71046)
> I'll do the interim fix, which is to disallow the use of AspectJ
> pointcut tokens as identifiers, and then probably will be able to
> address this issue properly when I've finished the move to the new
> parser generator. (Sorry, this problem probably arose as the result
> of a fix to a different problem in the parser generator; I'm really
> surprised that the test suite didn't pick it up, because we have test
> cases for it, but I'll update those as well, so this was a
> particularly good catch--thanks.)
My pleasure. And thank you for the fix.
> >I assume that, beyond the syntax error, I also have a scope
> problem,
> >searching for methods in the first part and classes in the second...
> but
> >there is more...
>
> No, I think you're fine here.
Good.
> >After reading the sample queries again, I realized that I could do
> the
> >same with a variation of
> >
> >"sourceof(relationship invokes(method * foo(..), in(concern C1))"
> >
> >I would have to replace the "in..." part with something similar to
> [2].
> >But no success with that one, either. :-(
>
> Fortunately, it's the same problem as for "within". Same fix will
> address it.
Great.
> >Now, once I have (somehow) done that, I also want to change the
> logical
> >and to a logical not to find those elements that I filtered out
> before.
>
> Should work fine once the parse problem is addressed. (Do you know,
> incidentally, that you can use ! or -, where - lets you remove one set
> of elements from another (e.g., A-B will give you the set of things
> that are in A but not in B)? It's quite often MUCH cleaner (and
> faster) than using !, so I wanted to be sure to point it out to you.
Thank you. I knew of "-" and was hoping that it would help me... Once I
got the fix installed, I'll try it out.
> >I am certain that this is not really complicated, but I don't seem
> to
> >get this running.
>
> Sorry it caused you problems,
No big deal.
> but fortunately, I think it's a 5-minute workaround, so I may even
> have you running today :-). Thanks for raising the issue!
As always, my pleasure.
Juri
