Hi,
It's difficult to avoid an emotional outburst at this type of thing.
I'm completely shocked that sweeping changes of this nature go
unannounced on this mailing list. Sorry, a blog doesn't cut it...
It's clear the current state is woefully incomplete. I.e., we have
here the Gerrit query narrowed down to Hendrik's changes
https://git.eclipse.org/r/#/q/platform/eclipse.platform.ui+owner:%22Hendrik+Still%22,n,z
--
Matthias
On Thu, Aug 29, 2013 at 7:46 AM, Lars Vogel lars.vo...@gmail.com wrote:
Hi Eike,
this is a GSoC done by Hendrik (cc) and was announced
Hi
On 29/08/2013 08:50, Ed Merks wrote:
It's difficult to avoid an emotional outburst at this type of
thing. I'm completely shocked that sweeping changes of this
nature go unannounced on this mailing list. Sorry, a blog doesn't
cut it...
Hi Ed,
I'm deeply sorry for the missing communications. I was not aware that such
things should be announced on this list.
Sorry for that.
I'm currently within a customer workshop so I look at your feedback with
regards to the content tonight.
Best regards, Lars
Am 29.08.2013 09:52 schrieb Ed
I should also add that I'm the primary mentor of Hendrik so definitely the
missing communication is completely my fault.
Best regards Lars
Am 29.08.2013 09:52 schrieb Ed Merks ed.me...@gmail.com:
Hi,
It's difficult to avoid an emotional outburst at this type of thing. I'm
completely
Hello,
as part of my Google Summer of Code Project I'm currently responsible
for the changes in the JFace Viewers, which leads to your warnings.
I fully understand your concerns about the incomplete generification of
the viewer classes. We intended to have small reviews, but I agree that
Hendrik,
Yes, I think reverting the changes would be best. Thanks for your
understanding.
Not to rain on anyone's parade, but respectfully suggest the platform
team should reconsider the gain verses the client impact for generifying
the JFace APIs. Designing generic containers isn't
On 08/29/2013 02:36 PM, Ed Merks wrote:
Not to rain on anyone's parade, but respectfully suggest the platform
team should reconsider the gain verses the client impact for
generifying the JFace APIs. Designing generic containers isn't easy,
and it's all too easy to make mistakes that will be
Michael,
Comments below.
On 29/08/2013 3:25 PM, Mickael Istria wrote:
On 08/29/2013 02:36 PM, Ed Merks wrote:
Not to rain on anyone's parade, but respectfully suggest the platform
team should reconsider the gain verses the client impact for
generifying the JFace APIs. Designing generic
Hi Mikael,
For me it's very hard to value the benefits of a generified Viewer framework. Personally I'd definitely not need that
but I'm willing to accept that other have other opinions on this question.
If this fundamental change (in the light of its impact to existing code) is welcomed by a
On 08/29/2013 04:19 PM, Eike Stepper wrote:
I'd better disable a compiler check (or findbugs rule, for that
matter) than risk that any new potential problem gets overlooked in a
sea of warnings that nobody ever wants to address. Once you've got
more than 5 warnings in the problems view, you'll
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. Most of the EMF-based use-case I've seen introduce a kind
of Labeled
+1 on working on a separate branch. I can't target 4.4 right now
because of the new warnings that I can't fix and we have this kind of
warning set to error.
Regards,
Marc-Andre
On Thu, 29 Aug 2013 12:36:38 +0200
Hendrik Still hendrik.st...@gammas.de wrote:
Hello,
as part of my Google
You raise good arguments as always Ed. I will attempt to summarize and
respond to some of the comments raised in this thread.
Q: Should JFace be generified at all.
As with most library generifications there are pros and cons that we can
probably debate all day. I still think on balance it
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
John,
Comments below.
On 29/08/2013 6:37 PM, John Arthorne wrote:
You raise good arguments as always Ed. I will attempt to summarize and
respond to some of the comments raised in this thread.
Q: Should JFace be generified at all.
As with most library generifications there are pros and cons
- Original Message -
From: John Arthorne john_artho...@ca.ibm.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Sent: Thursday, August 29, 2013 7:37:17 PM
Subject: Re: [cross-project-issues-dev] JFace Generics
You raise good arguments as always Ed. I will attempt to
On 08/29/2013 06:51 PM, Ed Merks wrote:
public E[] getElements(I inputElement) {
return (E[])inputElement.toArray();
}
I may have missed something, but wouldn't the following implementation
be a valid solution?
public E[] getElements(I inputElement) {
return
From: Mickael Istria mist...@redhat.com
I may have missed something, but wouldn't the following
implementation be a valid solution?
public E[] getElements(I inputElement) {
return inputElement.toArray(new E[inputElement.size()]);
}
You can't instantiate arrays of generic type. I think
19 matches
Mail list logo
