[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Taking working copies in account when doing JavaModel operations
|
Passing an empty working copy should do the trick.
Philippe_Mulet@oti.
com To: jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
jdt-core-dev-admin@ Subject: Re: [jdt-core-dev] Taking working copies in account when doing JavaModel
eclipse.org operations
01/25/2002 05:52 PM
Please respond to
jdt-core-dev
Good point, we need to look on how to do this too.
Dirk_Baeumer@xxxxxx
m To:
jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
Erich_Gamma@xxxxxxx
jdt-core-dev-admin@ Subject: Re:
[jdt-core-dev] Taking working copies in account when doing JavaModel
eclipse.org operations
01/23/2002 11:26 AM
Please respond to
jdt-core-dev
Yes, but there is one option missing needed for refactoring. We need the
ability to mark a CU as deleted although it still exists on the file
system. Is this something the new infrastructure will provide as well.
Dirk
Philippe_Mulet@xxxxxx
m To: jdt-core-dev@xxxxxxxxxxx
Sent by: cc: Erich_Gamma@xxxxxxx
jdt-core-dev-admin@ec Subject: [jdt-core-dev] Taking
lipse.org working copies in account when doing JavaModel
operations
22.01.2002 15:05
Please respond to
jdt-core-dev
Working copies are not connected from the JavaModel, they are created on
demand to perform local operations which can then be commited onto the
JavaModel.
They can see other pieces of the JavaModel through name resolution, but
they cannot see any other working copy, since there is no mechanism in the
JavaModel to cause working copies to shadow their original compilation
unit. This is annoying when performing operations which involve some name
resolution, since the referenced working copies are being ignored (until
they are saved).
We are investigating ways to have multiple working copies to be considered
at once by JavaModel operations. We currently are leaning towards a
solution where some operations could take in argument a set of working
copies to be considered (taking precedence over the normal Java model). We
can imagine having the search engine and the type hierarchy resolver be
equipped with such APIs; unsure about code completion and code selection
(maybe).
Given we are not planning on indexing working copies, we would force these
extra working copies to be passed to the name resolution engine (and likely
resolved even if unnecessary), thus they would de facto take precedence
over the JavaModel regular lookup mechanism (SearchableEnvironment).
As a consequence, passing extra working copies could penalize affected
operations, does this sound acceptable ?
_______________________________________________
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
