[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] 36888 - closing the gap between compilation units and working copies
|
See below <PM></PM>, also added some indentations.
|---------+------------------------------>
| | Dirk |
| | Baeumer/Zurich/IBM@|
| | IBMCH |
| | Sent by: |
| | jdt-core-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 05/19/2003 06:31 PM|
| | Please respond to |
| | jdt-core-dev |
| | |
|---------+------------------------------>
>-------------------------------------------------------------------------------------------------------------|
| |
| To: jdt-core-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [jdt-core-dev] 36888 - closing the gap between compilation units and working copies |
| |
>-------------------------------------------------------------------------------------------------------------|
See my comments below
<DB>
</DB>
Dirk
Philippe P
Mulet/France/IBM@
IBMFR To
Sent by: jdt-core-dev@xxxxxxxxxxx
jdt-core-dev-admi cc
n@xxxxxxxxxxx
Subject
[jdt-core-dev] 36888 - closing the
05/19/2003 05:19 gap between compilation units and
PM working copies
Please respond to
jdt-core-dev@ecli
pse.org
Please answer to jdt-core-dev@xxxxxxxxxxx.
This work item is intending to ease manipulating of working copies for
clients. As of today, there are currently two typical users:
long lifecycle: editor. As long as the editor is openend, a working
copy is kept active, and will be shown in various views, and be
updated as changes are notified. In particular, the package view must
handle the lazy creation of working copies as it shows units which
can then be opened in editor. In order for several editors (opened in
different perspective on the same unit) to share their contents, we
support a notion of shared working copies (we will answer back the
existing one if already active).
short lifecycle: refactoring. A working copy is created for a short
duration, a few changes are performed, then it is discarded. No need
to react to changes in the meantime, but need to be able to have
changes performed simultaneously amongst several units to be aware of
each other.
Goal
+ Provide a way to edit directly a compilation unit. Since working copies
are used to update units, a compilation unit should implicitly provide a
built-in working copy used for the Java editor. In practice, a handle
onto a compilation unit would remain the same whether it is reflecting a
file or an editor contents.
+ Other shared working copies should implicitly be aware of each other.
For instance, when refactoring performs a change across several units at
once, these modification must be visible to other refactored units:
search, name resolution, etc... In particular, the built-in working
copies associated with units should be aware of each other.
Proposal
+ ICompilationUnit is enrished to support built-in working copy behavior,
and thus working copy behavior is directly spec'ed there.
A compilation unit handle reflects the filesystem until it is toggled
into working mode (#becomeWorkingCopy()) and until it exits this mode
(#discardWorkingCopy()).
+ Other clients needing working copies would register for an operation
relative to this specific client (WorkingCopyOwner). In order to
register a client working copy owner, a WorkingCopyOwner#run(Runnable)
action would be invoked, and for the duration of this operation, all
subsequent working copies created by ICompilationUnit#getWorkingCopy()
would be owned by this very client. These would automatically be aware
of each other and for this very client only; i.e., during this client
operation, its owned working copies would automatically take precedence
over the underlying resource (even if already opened in editor).
This is roughly what can be achieved today using shared working copies,
but the notion of client is currently explicit and only a few APIs are
able to support these shared working copies to achieve awareness (type
hierarchy and search). With the notion of an implicitly registered
client, all APIs would be untouched, and implicitely give precedence to
this client specific working copies.
API implications for 2.1 clients
+ Units open in editor would take precedence over the filesystem. This is
likely the behavior they need anyway. Thus when navigating inside a unit
element, they may now see unsaved changes.
IWorkingCopy would be deleted, since no longer needed as a separate
entity (no more gap).
+ Shared working copies would be the default behavior. If needing more
than one working copy on the same unit at once, then a different client
should be registered. Thus the support for arbitrary individual working
copies would disappear.
Example: Refactoring wants to rename a field declaration
+ It performs a search for references to this field, and finds matches in
term of true compilation units. Note that since these compilation units
have built-in working copy support, these matches could reflect unsaved
editor contents.
+ Refactoring decides to update these references, and creates working
copies for these so as to edit them.
+ From thereon, all resolution actions would implicitly consider these
refactoring working copies in place of the original units.
+ However, if performing a further reference search outside these
refactoring working copies, a regular unit handle would be returned, and
it would need to be converted into a working copy again before being
edited as the refactoring client.
+ At any time, using IPackageFragment#getCompilationUnit would answer back
the original unit (either associated file contents or editor contents).
<DB>
Basically this means that we don't get a client world for packages and
projects. Is this correct? From refactoring we have the need that we
are able to create a new class in a package (without having the CU on
disk). This new compilation unit should be consider by operations like
search, type hierarchy, AST building, type bindings, ...
What happens if I call IPackageFragement#getCompilationUnit() in this
case. Will the new CU be part of the result ?
Additional questions are:
- how can we delete a CU from a package in the refactoring world ?
- if the package fragment always returns the original unit will
becomesWorkingCopy always convert the CU into the same refactoring
working copy as long as there exists one?
</DB>
<PM>
Initially our intent was that IPackageFragment#getCompilationUnit() would
always answer primary client units (file or editor contents). But indeed
for
consistency reason, it should also give precedence to current client
owned
working copies. The rational for our initial reserve was that we were
afraid
of some client still being inadvertently active while some callback is
invoking
code from JDT/UI which would now implicitly access the active client
layer by
mistake. However, other type of actions (search, type hierarchies,
etc...) would
also cause this to happen. So in a consistent manner,
IPackageFragment#getCompilationUnit()
should also find existing owned working copies as well.
When it comes to deleting virtually, this could be achieved by marking
working copies as such,
we currently do not support this, but could add it. Additions would be
already supported, since
working copies can be created on not yet existing resources.
If a unit was already a working copy, then yes likely, #becomeWorkingCopy
would answer back the same
one, though you could check #isWorkingCopy() prior to doing it.
BecomeWorkingCopy is rather meant for the
primary world only to achieve handle stability.
Also note that there would be no support for creating working copies of
package fragments.
</PM>
Question/Answers
Q: How can I distinguish in between a filesystem unit versus an editor
working copy ?
A: The handle remains stable, but it can be asked whether it is a working
copy or not (#isWorkingCopy).
Q: How can I get the contents of the original compilation unit, once it is
open in editor ?
Use resource API to read its contents.
Q: What happens if a unit opened in editor is modified on the filesystem ?
A: Once a compilation unit is opened in editor, the editor changes will
take precedence over the filesystem resource changes. In practice,
unless listening to resource changes, there will no longer be a way to
notice these, since the editor contents is implicitly hiding the file
contents.
Q: Can client code be nested in each other ?
A: Yes, registering a client would support nesting. Only the most specific
client would be active at once.
Q: Is becomeWorkingCopy()/discardWorkingCopy() a good name for the
activating the built-in working copy ?
A: Unclear. Maybe it should rather clearly state that this is a reserved
working copy for editors ? Suggestions are welcome.
Q: Would the builder see the unsaved editor contents through the built-in
working copy support ?
A: No, this would only be an artifact for the Java model tools (search,
codeassist, formatter, dom, eval) which aren't used by the Java builder.
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
