[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Source Lookup Path proposal
|
good comments Darin, except...
>"type pattern" (Gamma, et al)
I cannot take the credit for this one. The Type Object pattern was written
up
by Ralph Johnson and Bobby Woolf.
--erich
Darin Wright
<Darin_Wright@ca.
ibm.com> To
Sent by: platform-debug-dev@xxxxxxxxxxx
platform-debug-de cc
v-admin@eclipse.o
rg Subject
Re: [platform-debug-dev] Source
Lookup Path proposal
11/27/2003 08:05
PM
Please respond to
platform-debug-de
v@xxxxxxxxxxx
Thanks for the design proposal. Overall, the goals and the proposal are in
synch with what we'd like to acheive with regards to generic source lookup
facilities in the debug platform.
Here are my initial comments.
* Terminology
- Rather than use the term "Source Location Manager"
(ISourceLocationManager) to describe the root source locator that manages
contributed (model specific) source locators, I propose that we use the
term "Common Source Locator" (ICommonSourceLocator). I realize this is
confusing, since you have used the term "ICommonSourceLocator" to describe
a participant in the source lookup scheme. I'd like to call each
participant (model specific source locator), an ISourceLocatorParticipant.
Thus, there would be an implementation of CommonSourceLocator provided in
the debug platform that manages a set of source locator participants, which
are contributed by each launch config type that uses the generic source
lookup facilities. Note: in the debug platform, we have used the term
"manager" to refer to global managers like the "breakpoint manager" and
"launch manager" - thus I want to avoid! using the term "manager" for
something that there are many instances of.
- For similarity with other extension points in the debug platform, I'd
like to use the "type pattern" (Gamma, et al) for source locations. Thus, a
"source location factory" would become a "source location type", of which
there can be instances. The type is responsible for creating instances and
persisting instances (mementos). The net result is renaming
ISourceLocationFactory to ISourceLocationType.
- Rather than having two extension points for the GUI components of a
source location type, I'd recommend one "sourceLocationPresentation"
extension point containing attributes for an "icon" and "browser".
* Implementation
- The ISourceLocationType should be responsible for generating mementos for
its source locations, and re-creating source locations from mementos. This
provides more flexibility on the underlying implementation classes (i.e.
the source location implementation class can change - only the factory
needs to know what class is to be used). The implementation could have the
source location generate mementos if desired - but that can be an
implementation detail. Thus, the methods getMemento() and
initializeFrom(..) would be moved to ISourceLocationType. As well, an
ISourceLocation would have an accessor method to get its associated
ISourceLocationType. The methods that create/restore source
locations/mementos should be allowed to throw exceptions in case of currupt
mementos or unsupported source locations.
- Generally, API interfaces should not have setters for things which are
retrieved from XML - for example ISourceLocationType.setLocationName(...)
and setLocationID(..). Instead, the setter methods are only defined in the
implemetnation classes which are internal. Somewhere, we will need a
manager to load/maintain the initial set of contributed source locations
types. Since the API is small (i.e. getSourceLocationTypes()), we may be
able to add this to something like the launch manager.
- Rather than having an IDefaultSourceLocationComputer, I suggest that
there is an "ISourcePathComputer". The method defined on this interface
would be "computeSourceLocations(..)" given a launch configuration. (This
should also accept a progress monitor in case the computation is
expensive). I don't think there is a need for the method
"isDefaultSourceLocation" on ISourceLocation. Rather, an implementation of
DefaultSourceLocation in the debug platform can be instantiated on a launch
configuration. The configuration's associated source path computer will be
queried for its default source locations, and be stored as children of the
default source location. The "default" children are never stored explicitly
in mementos - rather the default source location has a memento, and it
regenerates its children lazily when queried. The tricky part is to know
when the children might need to be re-computed. For ex! ample, the source
path computer for a Java application computes a source path based on a
project's build path (or config's runtime classpath). When the build path
changes, so should the source lookup path. Thus a source path computer may
need a lifecycle. It should be created on a launch configuration, and
disposed on completion. This way the source path computer can listen to
changes in the config (or whatever it needs to do), and update as required.
- Currently, the propsoal states that each source locator must take care of
handling of duplicates. I think the common (root) source locator should
handle this. Otherwise, each source location participant could prompt the
user for duplicates (which could result in multiple dialogs when searching
for one source element). As well, it would be beneficial to centralize the
selection dialog. Thus, I think an implementation of ICommonSourceLocator
would be defined in the debug UI to handle this. As well, an
ISourceLocatorParticipant would not extend ISourceLocator - the API instead
would return for multiple source elements - i.e.
findSourceElements(IStackFrame frame, boolean duplicates).
* User Interface
- My main concern here is the "double dialog". That is, a user has to go
through several layers of dialogs to add a source location. First they must
choose the type of location to add, and then configure the selected
location type (for example, choose the project(s) to add). I'm not sure
what we can do about this since source location types are extensible, and
the number of buttons on the source tab would not be fixed. However, we
should consider how we might be able to simplify this.
* Proceeding
- To proceed, I suggest that I take the interfaces/extension points you
have provided in your proposal an integrate them into "internal" packages
in the debug platform (HEAD, 3.0 stream). You can then provide (contribute)
an implementation based on the interfaces (and comment on the interfaces).
Once we have things working, we can promote the interfaces to API.
Darin
Kristen
Desarmo/Toronto/IBM@IBMCA To:
Sent by: platform-debug-dev@xxxxxxxxxxx
platform-debug-dev-admin@ecl cc:
ipse.org Subject:
[platform-debug-dev] Source Lookup Path
proposal
11/20/2003 12:17 AM
Please respond to
platform-debug-dev
The attached document outlines a proposal for source lookup that will be
contributed to Eclipse 3.0. The goal of this solution is to create a common
source lookup mechanism that will make implementing source lookup easy and
consistent for all debug adapters. Please respond to this mailing list
with any comments, questions, or suggestions.
(For those who have seen earlier drafts of this document, the major
additions are default source location support and the concept of a source
location having visible child source locations.)
Thanks!
Kristen Desarmo
Debugger Development
IBM Toronto Lab
#### SourceLocation.doc has been removed from this note on November 27,
2003 by Darin Wright
