[ajdt-dev] Re: search function design

[Mik.Kersten@xxxxxxxx]

"Arno Schmidmeier" <Arno.Schmidmeier@xxxxxxxxxxxxxx> wrote in message
news:anu751$rih$1@xxxxxxxxxxxxx...
. . .
> > You suggest adding the elements "type, constructor, method, field and
> > package" to the AspectJ search page.  This brings up the issue of how we
> > separate functionality between the AspectJ search page and the Java
search
> > page in the search dialog.  Since search for those items already exists
on
> > the Java search page, I would propose leaving them there.  However,
since
> > we will soon be based on the Eclipse compiler, a search for a "type"
> > should then also return aspects as well.  So the Java page will have the
> > ability to search for at least that AspectJ-related object.  That means
> > the line is a little blurred between the two pages.  What do people
think
> > is the right solution?  Do we repeat an aspect-only search on the
AspectJ
> > page?  Or do we keep all type searching together in one place only on
the
> > Java page?
>
> I would suggest searching everything in one place, just the java page.
> Just because classes are nearly a total subset of aspects. (OK the
> construction issue, but you can easily work around that) ...
> My analogy:
> In an C/C++ IDE you do not have different search windows for structs and
> classes.

I agree with Arno that splitting up the AspectJ and Java parts in is
problematic since an AspectJ programmer should not need to make a conceptual
split between the two when searching.  I suggest that we duplicate the Java
Search page and extend it to include AspectJ declarations.  Then we can take
the more interesting search facilities that you're talking about and create
a "Crosscutting Search" page.

Borrowing from Julie's earlier message, the "AspectJ Search" would extend
the "Search For" to include the named :
- named pointcut
- inter-type declaration
- aspect (if we decide to break Type into Class and Interface)

There are some unnamed AspectJ members that could also be useful to search
if a limited scope is used (e.g. find all delcare parents in this package):
- advice
- pointcut
- declare warning/error
- declare parents
- delcare soft

In addition to the current 6 options "Limit To" should probably contain:
- before (for advice)
- after (for advice)
- around (for advice)
- message (for declare warning/error)

That last one is important for finding which declare is causing a particular
task list error or warning to show.

Everything in the "AspectJ Search" page can be searched from the sources and
does not require a compile.  This isn't true for the pointcut related
searches that you're describing.  Those searches are considerably different
from what users expect in a Java search, and will require a different UI.
So I think they deserve their own "Crosscutting Search" page.  I also think
that we've filled up the UI real-estate on the "AspectJ Search" page.

> > Regarding your comments on searching for pointcuts, in your first use
> > case, you suggest selecting a block of code and searching for pointcuts
> > that pick out join points in that block (if I read it right).  Mik, can
> > you comment on the feasibility of selecting a block of code to search in
> > this way?  If that's not possible, is it easier to specify a particular
> > type, method, or field and search for pointcuts that affect it? (should
> > achieve almost the same function (not quite as specific), with a
different
> > UI).
>
> This feature is very important for refactoring. With AspectJ you do today
> refactoring in following way.
>
> 1. You select a line of code.
> 2. You look and try to find the pointcuts which may affect that block of
> code.
>    and the advices of this code.
> 3. You refactor it.
> 4. You try to fix these pointcuts, so that the advices are applied in the
> correct order again.
> 2. and 4. are manually error phrone tasks, even in small and medium sized
> projects. if it gets to the large scale ist getting terrible. You start to
> think twice if you want to refactor. ...
> Tool/Search support would be of a great value.
>
> My current ultimate dream would be a fully functional aspectJ aware
> refactoring browser.   But I keep on dreaming. ... ;-)
>
> > Your second pointcut use case is interesting (searching for all
pointcuts
> > that share join points with a specified pointcut, again, if I'm reading
> > you right).  Mik, can you comment on the feasibility of implementing
this
> > one from an AspectJ perspective?
>
> This is from my opinon the most critical search function, because it is
> currently the most perfomed action in debugging large scale AspectJ
> projects.

I also think that the search facilities should cover what's required by
AspectJ-related refactorings.  JDT's search does a good job of that for
Java.  The goal is to eventually support AspectJ-aware refactorings and AO
refactorings in AJDT.  But those will use similar pointcut-based searches to
the ones described above, and it would be good to expose them to the user
before we make AspectJ-specific refactorings work.

We should focus on getting the core "AspectJ Search" right first, but keep
in mind use cases like Arno's for defining the "Crosscutting Structure"
searches that we want to expose.

Mik

--
Mik Kersten
Development Tools Lead
AspectJ Team, Palo Alto Research Center
http://www.parc.com/mkersten