Community
Participate
Working Groups
TextSelection can host a reference to the source document. In many cases, knowing the source document is very valuable and many clients could take advantage of it. TextSelection should provide a public getter for the document.
getDocument() method is currently protected, and TextSelection allows subclassing. Some existing class may already override getDocument() and keep the package visibility. If we make the visibility `public` in TextSelection, extensions overriding it with a more restricted visibility would show a compilation error. What would be the best procedure to handle this? Should we create a new public final method that delegates "getDocument()"? If so, how to call it? @Dani: Your advice would be extremely valuable there.
Is there a concrete use case for this?
Yes, see bug 521960 which has to deal with reflection. In general, just adding that makes it possible to adapt a TextSelection to something, whereas the lack of public accessor for Document makes it impossible to adapt or use a TextSelection to define a common handler enablement for Project Explorer and Text Editor for instance (just check selection adapts to the desired type and the same handler cover both).
I also happen to use a similar adapter (with the same need for a getter) in BlueSky.
and also in LSP4E today, where I just want to check whether the selection is a TextSelection and whether the "document being selected" is associated with a language server. Now that I know a TextSelection can provide the document, I see usage of this method everywhere and many handlers made more generic by relying on the selection rather than on the editor type.
(In reply to Mickael Istria from comment #3) > Yes, see bug 521960 which has to deal with reflection. Reflection is a no go. It is not maintainable. The text selection is meant to be used along with viewers and is a UI concept. The document is internal knowledge that must not be revealed from the selection itself.
This request/bug is exactly necessary to avoid reflection in clients such as JDT. Why do you mark it as WONTFIX ?
(In reply to Mickael Istria from comment #7) > This request/bug is exactly necessary to avoid reflection in clients such as > JDT. Why do you mark it as WONTFIX ? Since it is not OK to access the document from the UI selection. I'd have to look at the other bug how to avoid reflection.
(In reply to Dani Megert from comment #8) > Since it is not OK to access the document from the UI selection. Why? I don't think it's a layer breaker as Document is part of jface.text, like TextSelection, and the API could say that the Document can be still be null.
(In reply to Mickael Istria from comment #9) > (In reply to Dani Megert from comment #8) > > Since it is not OK to access the document from the UI selection. > > Why? I don't think it's a layer breaker as Document is part of jface.text, > like TextSelection, and the API could say that the Document can be still be > null. Because when you get the selection (e.g. offset) from the text selection object, the document can already be changed and the data/selection you fetch from the document is wrong.
(In reply to Dani Megert from comment #10) > Because when you get the selection (e.g. offset) from the text selection > object, the document can already be changed and the data/selection you fetch > from the document is wrong. Ok, I see. It makes sense.
