Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] JFace Generics

Am 30.08.2013 10:23, schrieb Aleksandar Kurtakov:
Technical problems were, are and will always be here. I'm not trying to deflect technical criticism but as there are people interested in see value in JFace generification their contribution shouldn't be rejected because a technical problem is here. The "<? extends E>" type of suggestions/bugs is exactly what needs to happen, help people with your expertise to get better codebase. If this things has been developed in separate branch I would dare to say that noone would have looked at it and we would have been having same discussion at the time of branch merge, way later in the release cycle and with way more changes done in not the best way.

I think almost all of this argumentation is totally wrong and misleading.

1) We're not talking about entirely new features that should be tested early by exactly those that want to test them early and that just don't affect the majority of others. We're talking about one of the most widely adopted APIs in the platform.

2) Community testing and feedback is certainly a good thing. But forcing all adopters to become alpha testers is a totally different thing. Before that happens I expect a reasonable amount of the platform's own *usage* of these new APIs and SPIs to be migrated and tested. Not to talk about sufficient test suites. *That* gives good feedback and helps to avoid embarrassing situations when the new code is finally dumped on the public.

I've done a very quick research in my current target platform: ComboViewer seems to be the only concrete viewer class that has been generified. I couldn't find a single *usage* of that class that has been migrated to the new form. Not even ComboBoxViewerCellEditor that is in JFace itself. Please, please prove me wrong! I would bet that most of the possible problems with the generification would have become obvious almost immediately.

I'm totally against this silent attempt to remove the least bit of responsibility for the quality of existing APIs from the providers of these APIs. There must be better ways to attract more contributions.



Back to the top