| Re: [cross-project-issues-dev] JFace Generics |
|
Mickael, Comments below. On 29/08/2013 4:48 PM, Mickael Istria
wrote:
You're right when saying that ITreeContentProvider seems indeed to be the place where generics don't provide much value. But generic in a viewer in general can help, especially when it comes to implementing the LabelProvider.Again it assumes a uniformity of items in the view. Perhaps that's often the case in list views, but rarely the case in trees... And as I've already explained, a generic E[] return type is highly questionable in the first place, limiting one's ability to provide generic implementation classes. Most of the EMF-based use-case I've seen introduce a kind of Labeled type which contains common stuff (id, label, comment...).They're just adapters, that the label and content providers delegate to, they're not the actual objects in the tree itself. Those can be any type of object, so java.lang.Object is the only suitable choice. It would be nice if I could tell my Viewer that all contents will actually be Labeled objects and avoid some (useful or useless) casts written by the developer because of the fact he was not sure of what's exactly in the TreeViewer.That's totally not applicable for EMF's use of providers... For other "raw" viewers (ListViewer, TableViewer, ComboViewer...) where all items are generally of the same Type such generics seem totally relevant to me. WDYT?Again, the problem is with generically typed arrays. You can't simply generify your existing implementation, you have to change it, or just make it Object, which is pointless, because that's already the current assumption. But you're against questioning whether the merit outweighs the benefit? I don't want this change because I think the value is questionable at best. I think it will pollute the vast majority of the code with <Object> and <?> neither of which will provide value. So the % of cases where it has perceived benefit should be balanced against the % of code where it's just noise. I have no doubt that percent of benefit % isn't zero, but if the percentage is 2%, or 10%, then does that justify that the other 90% of the code should simply become more complex? We can ask such questions independently for things like ListViewer verses TreeViewer and I'm quite sure the % for ListViewer benefit will be higher than that for TreeViewer. So it means that legacy consumer projects have to slow down improvement on "core" projects?It's a question of improvement. I've already made it clear that if I really perceived this a source of significant improvement, I'd spend the time to reap the benefits of that improvement, but in actual fact, I will be spending my time sprinkling <Object> and <?> throughout my projects and conditionally in the templates. Now that there is/will be generics on Viewers, you'll see a bunch of new warnings, but it doesn't mean that EMF is worse and it doesn't put EMF at risk.Yes, it means EMF is worse, and it means that any APIs EMF provides will be worse. It's unacceptable for the code base to be in such a state. You'll have the choice: either keep this warnings visible,Unacceptable. or hide those warnings,Also unacceptable. or fix them.So there is only one choice so no choice. None of those solutions makes EMF or any project worse (but the 3rd one make it better).No, I feel it will just make it more complex, not better.
|