| RE: [ajdt-dev] AspectJ search in Eclipse - design |
I copied also my copies from the newsgroups list to this mailig list,
because mike suggested to use this list for that kind of discussion.
Please appologize, if I remembered mikes suggestion wrongly.
kind regards
Arno
Hi Julie,
Hi all,
As Aspects can implement an interface and aspects can be subclasses from
standard java-classes. So aspects can play the role of standard java
objects.
And users will use aspects also in this way, as soon as the experience
with aspects increases.
So the dialog needs "all" the search functionality of plain java.
IMHO it is educational mistake to separate the search functionality in
plain java and in aspectJ specific elements. Both of these dialogs/panel
should be closely tied together.
IMHO the body of advices should be as small as possible, because advices
can currently not be adviced. But extracted methods from an advice can be
adviced.
So aspects of experienced aspectJ programmers have quite a buch of methods.
Aspects tend to look like standard classes, with some pointcuts and
advices in them.
A very important search functionality is searching after "conflicts",
"unkown" pointcuts, and advices affecting, influencing and intercepting
code. I am aware that these search case are not very often performed in
standard java.
Additionally I added some comments below:
Hope these comments help.
I appreciate any comments on mine, too!!!!
As they help me understand how other users work with IDEs in
aspectJ-programs!!!
regards
Arno Schmidmeier
Chief Scientist
Sirius Software Gmbh
Julie Waterhouse wrote:
> Hi all,
> I'm in the preliminary stages of implementing an AspectJ search facility
> for ajdt. Following are some design ideas, thoughts and questions to the
> user community - feedback is encouraged.
> Search will be implemented as a new "AspectJ" page on the existing search
> dialog. I would expect it to behave in a similar manner to the Java
> Search page. There should be an entry field for text to search, which
> will accept wildcard searches. There should be a "case-sensitive"
> checkbox. There should be a set of things you can search for (see below),
> and the ability to restrict the search in appropriate ways (see below).
> You should also be able to restrict the scope of the search to workspace,
> selected resources or working set.
> I have included a link to a screen capture of a first pass at the search
> dialog. Note that this is something I threw together quickly, and I
> recongise that it's less than ideal. I include it here to better
> illustrate the following discussion. Input on the GUI is welcome, as it
> definitely needs more thought, but I think the design of how the search
> works must come first.
> Screen capture: http://members.rogers.com/30159374290/searchpage.html
> Reminder: on the Java search page, you can search for
> -type
> -constructor
> -method
> -field
> -package
> and limit your search to:
> -declarations (applies to all)
> -references (applies to all)
> -implementers (currently disabled, intended for interfaces)
> -all occurrences (applies to all)
> -read access (applies to fields)
> -write access (applies to fields)
> For the AspectJ search,
> The search for/limit to paradigm used by the Java search doesn't seem to
> hold up for AspectJ. In many cases (discussed below), you want to search
> for constructs (like advice or pointcuts) that affect a particular
> class/method/field (rather than searching for a subset of occurrences of a
> particular class/method/field).
> What should you be able to search for? Possibilities include:
> (a) aspects
> (b) pointcuts
> (c) advice
> (d) introductions
> (e) warnings and errors
> (f) softened exceptions
> (g) other?
* plus add the elements
> -type
> -constructor
> -method
> -field
> -package
from java. where type equals class and aspect!!! So you can drop then the
search aspect option from the list, if the search type option is available.
> Let's look at the issues with each of these in turn, in particular with
> how it might be appropriate to limit the search in each case:
> (a) aspects
> -Certainly it makes sense to search for declarations of an aspect. Are
> there any search limits that make sense here?
see above
> (b) pointcuts
> -This was the trickiest one to get my mind around...
> -You should have the ability to search for named pointcut declarations.
> Are there any search limits that make sense here?
> -What about all pointcuts that pick out join points in a particular type
> or method? Here, you might specify that you're searching for a pointcut,
> and then restrict the search to find only those pointcuts that pick out
> join points in a named class/method/field. Does this make sense? Is it
> useful? What about the primitive pointcuts used in advice - in that case,
> there's no explicit pointcut definition to return from a search - rather,
> we might find the advice that affects the named class/method/field (case
> (c) below). Is a search for named pointcuts, plus case (c) all that's
> useful, or is there something else lurking in here?
I agree searching with pointcuts is the most trickiest element.
And that is the point, where a developer needs as much support from the
tools as possible. I will describe in short the optimal search-use cases
for pointcuts, I have seen in my work, and by observing some other aspectJ
developers.
1. I select a block of code, enter the search dialog, and get a list of
all pointcuts (named/unnamed), who define joinpoints for this type of
block of code.
2. I select a pointcut, enter the search dialog and get a list of all
pointcuts , who have joinpoints (named/unnamed) with this pointcut in
common.
> (c) advice
> -I wouldn't think you'd want to search for all "before" advice, or all
> "after" advice etc. More likely you'd want to search for all advice that
> affects a particular class/method/field. In that case, it may again make
> more sense to search for advice and restrict the search to find only
> advice affecting a named class or method (this is the example illustrated
> by the screen capture).
I agree with you that simple search for before advices, or all after
advices is not very likely. Your use case is quite realistic.
Based on my experience I see there a much more important use case, which
is:
Which advices of a conflicting type advices the same joinpoints. (whithout
having a dominates subordinates relationship)
this search can be narrowed, by specific types, by selecting a given
advice.
Also I want to search after advices, which directly or indirectly (through
pointcut composition) use (or are affected, e.g. some pointcuts are
excluded through &&!) by a given pointcut.
> (d) introductions
> -Again, this would seem to work like advice where you would want to search
> for introductions, and restrict to those introductions affecting a named
> class (method/field don't seem to apply here).
> -Should a search for introductions find "declare parents" in the results
> as well as member introductions? Would these be better separated into two
> categories?
it must find it!
Also indirect introduction should be found. (e.g. container introduction)
E.g. introducing a method to an interface, and introducing this interface
to a class, aspect, etc.
> (e) warnings and errors ("declare error", "declare warning")
> -Would you want to search for these? One category or two? What kind of
> restrictions might make sense?
Quite likely, but not necessarily.
> (f) softened exceptions ("declare soft")
> -Would you want to search for these? What kind of restrictions might make
> sense?
Yes
> (g) other
> -Now that aspectJ will be built on the eclipse compiler, some things will
> come to us for "free". A search for implementers on the Java Search page
> (once enabled), would also return aspects in the result set. Would it be
> useful to have an "implementers" search on the AspectJ search page that
> returned only aspects that implement a specified interface?
> -Is there anything I've missed that would be useful to search for?
> Should the final GUI resemble anything similar to the included screenshot,
> I would expect at a minimum that the "Named" and/or "Affecting + Named"
> sections will be enabled/disabled as appropriate for each different type
> of search. Examples: (1) if "Advice" is chosen in the "Search for"
> section, the first "Named" will be disabled. (2) if Aspect is chosen,
> "Named" would be disabled, and the "Affecting" + "Named" pair would be
> enabled. (3) if "Pointcut is chosen, all would remain enabled.
> Comments and feedback most welcome.
> Regards,
> Julie Waterhouse
> AJDT Development Team
-----Original Message-----
From: juliew@xxxxxxxxxx
To: ajdt-dev@xxxxxxxxxxxxxxx; users@xxxxxxxxxxx
Sent: 9/19/02 3:59 AM
Subject: [ajdt-dev] AspectJ search in Eclipse - design
Hi all,
I'm in the preliminary stages of implementing an AspectJ search facility
for the Eclipse plugin (ajdt). I have posted some design ideas and
questions in a note on the ajdt newsgroup (eclipse.technology.ajdt).
I'm
looking for feedback from the AspectJ community with regard to what
kinds
of searches make sense and would be the most useful. If you have any
input, please join the discussion on that newsgroup.
Regards,
Julie Waterhouse
AJDT Development Team
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ajdt-dev