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.
I totally agree with you that this change is difficult and should be
implemented perfectly and that is has to be fully backward compatible.
And I am not against any technical debate on how to implement this the
best.
But you're against questioning whether the merit outweighs the benefit?
However, when it comes to warnings, here is how I understand your
comment: "I don't want this change because I've made efforts to get no
warnings, and this improvement will now show warnings on my code".
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.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
