PsiElement.copy()

Hi, Everybody,

We are about to change how PsiElement.copy() works: currently calling this
method copies the tree of the whole file. The reason for this is to have a
constistent tree, so that it would be possible to examine the parent
elements of the copy later. It seems though that most of the clients do not
need to look at parent elements,
and the overhead of copying the whole file is really huge and often
inacceptable.
So what I want to do in 5.0.3 (not in 5.0.2) is to copy only the subtree of
the element. The context of the copy would be the old element's parent, so
resolving references would work as before with the correction that the
references won't resolve to references in the copied file unless the
referenced element is in the copy itself. However it becomes illegal to
examine the psi of the copy parents with e.g. getContainingClass(),
getContainingFile() or getParent(). The code that needs this has to
explicitly call copy() for respective parent.

The places where we had to make modifications in our code were really few.
The question to you is, if you could survive this change in openapi in a
(not next) minor release, or should it be delayed until later?

Eugene.


2 comments

It's be nice if those calls would throw a helpful exception that explains why the parents are null, that way even someoen who doesn't follow the forums can find out why they're getting an error now.

0

Unfortunately this is quite difficult to implement:(

"Hani Suleiman" <hani@formicary.net> wrote in message
news:28404504.1126971833858.JavaMail.javamailuser@localhost...

It's be nice if those calls would throw a helpful exception that explains

why the parents are null, that way even someoen who doesn't follow the
forums can find out why they're getting an error now.


0

Please sign in to leave a comment.