Debug Expressions
This document describes a proposal for generic “expressions”
to be incorporated into the platform debug model and UI. This is intended to
allow specific debug architectures to provide implementations of expressions to
support features such as an inspector and/or watch list.
An _expression_ is a snippet of code that can be
evaluated to produce a value. The context/binding required to evaluate an _expression_
varies by debug model/architecture/language, and by user intent. For example, a
Java _expression_ requires a context in which to be compiled (a Java project),
and a thread in which to be evaluated. Furthermore, an _expression_ may need to
be evaluated at a specific location in a program (for example, at a
breakpoint/line where certain variables referenced in the _expression_ are
visible/allocated). A user may want to evaluate an _expression_ once to produce a
value than can be “inspected” iteratively (i.e. like a VAJ inspector), or they
may wish to evaluate an _expression_ iteratively producing new values each time
(i.e. as in a watch list).
The following definition of expressions is proposed:
·
An _expression_ is a debug element with two attributes –
an _expression_ (source code snippet, i.e. a java.lang.String), and a current
value (i.e. an org.eclipse.debug.core.IValue). The binding of an _expression_ is
implementation specific. That is, the time/location/context at which an
_expression_ is evaluated is up to each implementation. Expressions are required
to fire debug events to allow clients to know when an _expression_ has been
created, when an _expression_ has expired, and when the value of an _expression_
has changed. An _expression_ does not need to be bound to a debug target or
launch, and is allowed to return “null” when queried for its debug target or
launch.
The debug UI would provide
an “_expression_ View” (which would replace the current “Inspector View”):
·
The _expression_ view is similar to the variables view,
which displays expressions and their values. Values may be complex data
structures, as in the variables view, and have children that can be expanded
and viewed. The view would contain a “details” area, as the variables view
does, to show the details of a selected value.
·
A debug model presentation will be given the chance to
render an “_expression_”, but the debug UI will also provide a default icon and
label. This would allow specific implementations to provide special icons to
distinguish between “watch items” and “inspected items”.
·
The _expression_ view listens for debug events to know
when to update the view (i.e. as expressions are created, they are added to the
view; as expressions are terminated, they are removed from the view; and as
expressions are changed, their value is updated).
·
Standard remove/remove all actions will be available in
a view. When an _expression_ is removed, it will be sent a message to be
“disposed”, such that it can do any cleanup required. (Expressions can also
remove themselves from the view by firing a terminate event – for example, an
_expression_ that represents an object being inspected would terminate when its
VM terminates).
·
The creation of an _expression_ is controlled by clients.
There is no general way to enter/create an _expression_ – it is client defined.
For example, a Java _expression_ is created by performing an “inspect” action in
the java editor.
·
Expressions may be persisted across workbench
invocations. For example, “watch items” are expressions that are evaluated each
time a program suspends. Persistence is controlled by specific implementations.
That is, if an _expression_ is to be persisted, the _expression_ should be
re-created by its plug-in at startup and added to the _expression_ view.
·
The _expression_ view could be filtered by debug model
(similar feature request exists for breakpoints view). Thus, when a debug
target is selected, only those expressions that pertain to that debug model are
displayed. (The filter is controlled by a toggle button in the toolbar – i.e.
“show all expressions/show expressions associated with selected debug target”).
·
To support advanced _expression_ evaluation, the details
area of the variables and _expression_ view should allow typing (currently, it is
read-only). For example, this will allow the Java debugger to perform
evaluations in the context of a selected item in the variables view/_expression_
view. The “read-only” property of the details area could be dynamic, and could
be controlled by the IValueDetailListener inteface. For example, a flag could
be added to the interface that tells listeners if the value is read-only. This
could also provide support for a new method of “value changing” – i.e. entering
a new value and pressing CTRL-S. Clients can contribute actions to the detail
view pop-up menu using the standard workbench extensions. It would be nice if
we could also alow the contribution of code assist and formatting (not sure how
difficult this is). What we eventually want to have is a detail area that acts
like a display view when viewing “Java details”. Perhaps we could allow a debug
model presentation to supply its own “details area” widget/view. The debug UI
would provide a simple default view (what we have currently).
Copyright © 2001
Object Technology International, Inc.