Re: [jdt-core-dev] Taking working copies in account when doing JavaModel

[Dirk_Baeumer@xxxxxxx]

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@xxxxxxx Sent by: jdt-core-dev-admin@xxxxxxxxxxx 22.01.2002 15:05 Please respond to jdt-core-dev

To:        jdt-core-dev@xxxxxxxxxxx         cc:        Erich_Gamma@xxxxxxx         Subject:        [jdt-core-dev] Taking working copies in account when doing JavaModel operations

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