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.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|