Home » Modeling » EMF » More generics in EMF/JFace
| More generics in EMF/JFace [message #532432] |
Sun, 09 May 2010 22:41  |
 J.-P. Pellet
Messages: 71
Registered: July 2009 |
Member |
|
|
Hi,
I'm an EMF/JFace newbie. I've designed a fairly simple model as well as
various SWT/Jface GUI elements to edit parts of my model with the help
of JFace databinding. I'm quite happy with the result. However, I find
that many times, an increased usage of generics could improve the type
safety of EMF/JFace related code a lot.
For instance, one of the most useful things I'd like is if
EStructuralFeature was defined as EStructuralFeature<D,T>, where D would
be the declaring type, and T the feature type. Are there reasons not to
do this? Contrary to Field and Method in Java's own reflection system,
we do have the literals of all our structural features in EMF, which
could be declared with the full type information. Getting this
additional information (together with more generics in interfaces like
ILabelProvider, IObservableList, etc.) would be great; for now, I really
have the feeling that I'm dealing with Objects and a lot of casts all
over the place, which I'm uncomfortable with.
Any chance we'll be going this direction in the future?
Thanks a lot,
Jean-Philippe
[cross-posting this to eclipse.tools.emf and eclipse.platform.jface]
|
|
|
| Re: More generics in EMF/JFace [message #532448 is a reply to message #532432] |
Mon, 10 May 2010 06:27  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Jean-Philippe,
Comments below.
J.-P. Pellet wrote:
> Hi,
>
> I'm an EMF/JFace newbie. I've designed a fairly simple model as well
> as various SWT/Jface GUI elements to edit parts of my model with the
> help of JFace databinding. I'm quite happy with the result. However, I
> find that many times, an increased usage of generics could improve the
> type safety of EMF/JFace related code a lot.
>
> For instance, one of the most useful things I'd like is if
> EStructuralFeature was defined as EStructuralFeature<D,T>, where D
> would be the declaring type, and T the feature type. Are there reasons
> not to do this?
Yes.
> Contrary to Field and Method in Java's own reflection system, we do
> have the literals of all our structural features in EMF, which could
> be declared with the full type information.
True, but when we have such generated literals, we also have a generated
API that provides the full type safety.
> Getting this additional information (together with more generics in
> interfaces like ILabelProvider, IObservableList, etc.) would be great;
> for now, I really have the feeling that I'm dealing with Objects and a
> lot of casts all over the place, which I'm uncomfortable with.
Given the erased nature of Java-style generics, runtime type safety is a
bit of an illusion
>
> Any chance we'll be going this direction in the future?
No. We did consider it at the time, but it seems to me that in almost
cases where you'd benefit from such a thing you could better use the
generated API. One of the places you'd want to use it is in eGet, but
depending on whether the feature is multi-valued you'd get either
EList<T> or T.
>
> Thanks a lot,
> Jean-Philippe
>
> [cross-posting this to eclipse.tools.emf and eclipse.platform.jface]
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: More generics in EMF/JFace [message #532479 is a reply to message #532448] |
Mon, 10 May 2010 08:30 |
J.-P. Pellet
Messages: 71
Registered: July 2009 |
Member |
|
|
Ed,
Thanks for your answer. I have a few more questions/remarks...
> Given the erased nature of Java-style generics, runtime type safety is a
> bit of an illusion
What do you mean? If I use no raw types and there are no "unchecked"
warnings in my code, then I get run-time type safety even if generics
are implemented with erasure, no? Why would this be an illusion?
>> Any chance we'll be going this direction in the future?
> No. We did consider it at the time, but it seems to me that in almost
> cases where you'd benefit from such a thing you could better use the
> generated API. One of the places you'd want to use it is in eGet, but
> depending on whether the feature is multi-valued you'd get either
> EList<T> or T.
What's wrong with making multi-valued features map to
EStructuralFeature<D, EList<T>>?
> True, but when we have such generated literals, we also have a
generated API that provides the full type safety.
But sometimes it's nice to pass those features around and still know
what they types refer to. Can you give me some pointers on where to
start if I want to extend/customize the generator so that this
information is available to me in client code?
And now JFace: what about IObservableList and related databinding
interfaces? Any chance those will have a parametrized version soon?
Cheers,
J.-P.
|
|
|
| Re: More generics in EMF/JFace [message #532488 is a reply to message #532432] |
Mon, 10 May 2010 09:00 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
What would EStructuralFeature<D,T> help? The only area it would is when
calling eGet()/eSet() which are hidden anyways by EMF-Databinding.
JFace-Viewers can't use generics because it is constrainted to Java 1.3.
Tom
Am 10.05.10 00:41, schrieb J.-P. Pellet:
> Hi,
>
> I'm an EMF/JFace newbie. I've designed a fairly simple model as well as
> various SWT/Jface GUI elements to edit parts of my model with the help
> of JFace databinding. I'm quite happy with the result. However, I find
> that many times, an increased usage of generics could improve the type
> safety of EMF/JFace related code a lot.
>
> For instance, one of the most useful things I'd like is if
> EStructuralFeature was defined as EStructuralFeature<D,T>, where D would
> be the declaring type, and T the feature type. Are there reasons not to
> do this? Contrary to Field and Method in Java's own reflection system,
> we do have the literals of all our structural features in EMF, which
> could be declared with the full type information. Getting this
> additional information (together with more generics in interfaces like
> ILabelProvider, IObservableList, etc.) would be great; for now, I really
> have the feeling that I'm dealing with Objects and a lot of casts all
> over the place, which I'm uncomfortable with.
>
> Any chance we'll be going this direction in the future?
>
> Thanks a lot,
> Jean-Philippe
>
> [cross-posting this to eclipse.tools.emf and eclipse.platform.jface]
|
|
|
| Re: More generics in EMF/JFace [message #532696 is a reply to message #532488] |
Mon, 10 May 2010 21:04 |
J.-P. Pellet
Messages: 71
Registered: July 2009 |
Member |
|
|
> What would EStructuralFeature<D,T> help? The only area it would is when
> calling eGet()/eSet() which are hidden anyways by EMF-Databinding.
Even if eGet()/eSet() do not use this information, it would be useful.
Take the example of creating Table columns. A lot of repetitive things
have to be done while creating a column - manage sorting, set label and
icon provider, set layout data, etc., so I do this in a separate method,
and I use my own class EMFColumnData to save the needed info.
Simplified, the relevant part looks like this:
public class EMFColumnData {
public final EStructuralFeature feature;
public final IColumnLabelProvider labelProvider;
public EMFColumnData( EStructuralFeature feature,
IColumnLabelProvider labelProvider ) {
this.feature = feature;
this.labelProvider = labelProvider;
}
public interface IColumnLabelProvider {
String getText( Object element, Object feature );
}
}
Now, each time I implement IColumnLabelProvider I have to cast element
(which is the object represented by the column row) and feature (the
element's feature for this column). I'd love to declare it this way instead:
public class EMFColumnData<D,T> {
public final EStructuralFeature<D,T> feature;
public final IColumnLabelProvider<D,T> labelProvider;
public EMFColumnData( EStructuralFeature<D,T> feature,
IColumnLabelProvider<D,T> labelProvider ) {
this.feature = feature;
this.labelProvider = labelProvider;
}
public interface IColumnLabelProvider<D,T> {
String getText( D element, T feature );
}
}
And I'd avoid passing a feature with an incompatible type. In some other
places, in a utility method I would like to accept features that belong
to a given class BaseClass or its descendents only, and would enjoy
writing this:
void someMethod( EStructuralFeature<? extends BaseClass, ?> feature );
Does this look absurd to you?
What about other things like EClass<T>? Much in the vein of Class<T>?
> JFace-Viewers can't use generics because it is constrainted to Java 1.3.
Ouch! Is this going to change some day, soon? I understand that legacy
environment have to be supported, but it is too bad that it is at such a
cost for developers who can use Java 5 or 6.
Has no effort been made to introduce more generics into JFace
databinding? IObservableValue, IObservableList & co. are just begging
for a parametrized version... :-) I'd gladly invest some time in this.
Best,
J.-P.
|
|
|
| Re: More generics in EMF/JFace [message #532736 is a reply to message #532696] |
Tue, 11 May 2010 05:58 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Am 10.05.10 23:04, schrieb J.-P. Pellet:
>> What would EStructuralFeature<D,T> help? The only area it would is when
>> calling eGet()/eSet() which are hidden anyways by EMF-Databinding.
>
> Even if eGet()/eSet() do not use this information, it would be useful.
> Take the example of creating Table columns. A lot of repetitive things
> have to be done while creating a column - manage sorting, set label and
> icon provider, set layout data, etc., so I do this in a separate method,
> and I use my own class EMFColumnData to save the needed info.
> Simplified, the relevant part looks like this:
>
> public class EMFColumnData {
>
> public final EStructuralFeature feature;
> public final IColumnLabelProvider labelProvider;
>
> public EMFColumnData( EStructuralFeature feature,
> IColumnLabelProvider labelProvider ) {
> this.feature = feature;
> this.labelProvider = labelProvider;
> }
>
> public interface IColumnLabelProvider {
>
> String getText( Object element, Object feature );
>
> }
> }
>
> Now, each time I implement IColumnLabelProvider I have to cast element
> (which is the object represented by the column row) and feature (the
> element's feature for this column). I'd love to declare it this way
> instead:
>
> public class EMFColumnData<D,T> {
>
> public final EStructuralFeature<D,T> feature;
> public final IColumnLabelProvider<D,T> labelProvider;
>
> public EMFColumnData( EStructuralFeature<D,T> feature,
> IColumnLabelProvider<D,T> labelProvider ) {
> this.feature = feature;
> this.labelProvider = labelProvider;
> }
>
> public interface IColumnLabelProvider<D,T> {
>
> String getText( D element, T feature );
>
> }
> }
>
> And I'd avoid passing a feature with an incompatible type. In some other
> places, in a utility method I would like to accept features that belong
> to a given class BaseClass or its descendents only, and would enjoy
> writing this:
>
> void someMethod( EStructuralFeature<? extends BaseClass, ?> feature );
>
> Does this look absurd to you?
Ok. I can see your use case.
>
> What about other things like EClass<T>? Much in the vein of Class<T>?
>
>> JFace-Viewers can't use generics because it is constrainted to Java 1.3.
>
> Ouch! Is this going to change some day, soon? I understand that legacy
> environment have to be supported, but it is too bad that it is at such a
> cost for developers who can use Java 5 or 6.
>
No. I started on working for this in e4 but didn't had time to implement
it fully. The viewers in UFaceKit are generified but they have not the
same featureset JFace-Viewers have today.
> Has no effort been made to introduce more generics into JFace
> databinding? IObservableValue, IObservableList & co. are just begging
> for a parametrized version... :-) I'd gladly invest some time in this.
>
Same applies to databinding. We try to keep the level very low (think
about embedded systems).
Tom
|
|
|
| Re: More generics in EMF/JFace [message #532835 is a reply to message #532479] |
Tue, 11 May 2010 10:51 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Jean-Philippe,
Comments below.
J.-P. Pellet wrote:
> Ed,
>
> Thanks for your answer. I have a few more questions/remarks...
>
>> Given the erased nature of Java-style generics, runtime type safety
>> is a bit of an illusion
>
> What do you mean? If I use no raw types and there are no "unchecked"
> warnings in my code, then I get run-time type safety even if generics
> are implemented with erasure, no? Why would this be an illusion?
Because libraries themselves are rife with unchecked warnings, so one
must rely on the tested correctness of the type safety they provide
rather than be absolute guaranteed of it. No doubt the collection
classes are free of such errors, but that's not guaranteed by the
compiler nor fail-fast at runtime. That's not even pointing out that it
can easily and accidentally be subverted with problem showing up far
from their origin.
>
>>> Any chance we'll be going this direction in the future?
>> No. We did consider it at the time, but it seems to me that in
>> almost cases where you'd benefit from such a thing you could better
>> use the generated API. One of the places you'd want to use it is in
>> eGet, but depending on whether the feature is multi-valued you'd get
>> either EList<T> or T.
>
> What's wrong with making multi-valued features map to
> EStructuralFeature<D, EList<T>>?
Yes, there are bunch of approaches. One could even add more type
arguments so you might have EStructuralFeature<D, T, EList<T>> to
separate out the feature's type from the actual return type of the getter.
>
> > True, but when we have such generated literals, we also have a
> generated API that provides the full type safety.
>
> But sometimes it's nice to pass those features around and still know
> what they types refer to.
Yes, people made those arguments and in the edit, those sometimes
generally reduced to places where using the generated API was actually
more natural.
> Can you give me some pointers on where to start if I want to
> extend/customize the generator so that this information is available
> to me in client code?
Without sweeping changes in the Ecore model itself, I don't see how this
will pan out.
>
> And now JFace: what about IObservableList and related databinding
> interfaces? Any chance those will have a parametrized version soon?
It would be nice if the platform could decide between supporting Java ME
stuck in the 1.4 days verses Java as it evolves to 1.7, but it's hard to
please everyone with one thing.
>
> Cheers,
> J.-P.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: More generics in EMF/JFace [message #532860 is a reply to message #532736] |
Tue, 11 May 2010 11:57 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000707020105040408090401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Guys,
Comments below.
Tom Schindl wrote:
> Am 10.05.10 23:04, schrieb J.-P. Pellet:
>
>>> What would EStructuralFeature<D,T> help? The only area it would is when
>>> calling eGet()/eSet() which are hidden anyways by EMF-Databinding.
>>>
>> Even if eGet()/eSet() do not use this information, it would be useful.
>> Take the example of creating Table columns. A lot of repetitive things
>> have to be done while creating a column - manage sorting, set label and
>> icon provider, set layout data, etc., so I do this in a separate method,
>> and I use my own class EMFColumnData to save the needed info.
>> Simplified, the relevant part looks like this:
>>
>> public class EMFColumnData {
>>
>> public final EStructuralFeature feature;
>> public final IColumnLabelProvider labelProvider;
>>
>> public EMFColumnData( EStructuralFeature feature,
>> IColumnLabelProvider labelProvider ) {
>> this.feature = feature;
>> this.labelProvider = labelProvider;
>> }
>>
>> public interface IColumnLabelProvider {
>>
>> String getText( Object element, Object feature );
>>
>> }
>> }
>>
>> Now, each time I implement IColumnLabelProvider I have to cast element
>> (which is the object represented by the column row) and feature (the
>> element's feature for this column). I'd love to declare it this way
>> instead:
>>
>> public class EMFColumnData<D,T> {
>>
>> public final EStructuralFeature<D,T> feature;
>> public final IColumnLabelProvider<D,T> labelProvider;
>>
>> public EMFColumnData( EStructuralFeature<D,T> feature,
>> IColumnLabelProvider<D,T> labelProvider ) {
>> this.feature = feature;
>> this.labelProvider = labelProvider;
>> }
>>
>> public interface IColumnLabelProvider<D,T> {
>>
>> String getText( D element, T feature );
>>
>> }
>> }
>>
What actually interesting things can you do knowing D and T? They're
completely unconstrained so generically you can only assume
java.lang.Object as possible substitutions.
>> And I'd avoid passing a feature with an incompatible type. In some other
>> places, in a utility method I would like to accept features that belong
>> to a given class BaseClass or its descendents only, and would enjoy
>> writing this:
>>
>> void someMethod( EStructuralFeature<? extends BaseClass, ?> feature );
>>
I'm not sure how this pans out in context either....
>> Does this look absurd to you?
>>
>
> Ok. I can see your use case.
>
I'm still doubtful.
>
>> What about other things like EClass<T>? Much in the vein of Class<T>?
>>
At least this is simpler than the feature case, but I still argue its
utility is greatly limited. In the end, parameterizing the Ecore model
itself would have resulted in much more disruptive changes in all the
downstream usage, only a very very tiny portion of which would have
derived any real value from it. Look how quickly your example above
degrades into using ? all over the place.
>>
>>> JFace-Viewers can't use generics because it is constrainted to Java 1.3.
>>>
>> Ouch! Is this going to change some day, soon? I understand that legacy
>> environment have to be supported, but it is too bad that it is at such a
>> cost for developers who can use Java 5 or 6.
>>
>>
>
> No. I started on working for this in e4 but didn't had time to implement
> it fully. The viewers in UFaceKit are generified but they have not the
> same featureset JFace-Viewers have today.
>
>
>> Has no effort been made to introduce more generics into JFace
>> databinding? IObservableValue, IObservableList & co. are just begging
>> for a parametrized version... :-) I'd gladly invest some time in this.
>>
>>
>
> Same applies to databinding. We try to keep the level very low (think
> about embedded systems).
>
> Tom
>
--------------000707020105040408090401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
Comments below.<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:hsarli$sfk$1@build.eclipse.org" type="cite">
<pre wrap="">Am 10.05.10 23:04, schrieb J.-P. Pellet:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">What would EStructuralFeature<D,T> help? The only area it would is when
calling eGet()/eSet() which are hidden anyways by EMF-Databinding.
</pre>
</blockquote>
<pre wrap="">Even if eGet()/eSet() do not use this information, it would be useful.
Take the example of creating Table columns. A lot of repetitive things
have to be done while creating a column - manage sorting, set label and
icon provider, set layout data, etc., so I do this in a separate method,
and I use my own class EMFColumnData to save the needed info.
Simplified, the relevant part looks like this:
public class EMFColumnData {
public final EStructuralFeature feature;
public final IColumnLabelProvider labelProvider;
public EMFColumnData( EStructuralFeature feature,
IColumnLabelProvider labelProvider ) {
this.feature = feature;
this.labelProvider = labelProvider;
}
public interface IColumnLabelProvider {
String getText( Object element, Object feature );
}
}
Now, each time I implement IColumnLabelProvider I have to cast element
(which is the object represented by the column row) and feature (the
element's feature for this column). I'd love to declare it this way
instead:
public class EMFColumnData<D,T> {
public final EStructuralFeature<D,T> feature;
public final IColumnLabelProvider<D,T> labelProvider;
public EMFColumnData( EStructuralFeature<D,T> feature,
IColumnLabelProvider<D,T> labelProvider ) {
this.feature = feature;
this.labelProvider = labelProvider;
}
public interface IColumnLabelProvider<D,T> {
String getText( D element, T feature );
}
}
</pre>
</blockquote>
</blockquote>
What actually interesting things can you do knowing D and T? They're
completely unconstrained so generically you can only assume
java.lang.Object as possible substitutions.<br>
<blockquote cite="mid:hsarli$sfk$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">
And I'd avoid passing a feature with an incompatible type. In some other
places, in a utility method I would like to accept features that belong
to a given class BaseClass or its descendents only, and would enjoy
writing this:
void someMethod( EStructuralFeature<? extends BaseClass, ?> feature );
</pre>
</blockquote>
</blockquote>
I'm not sure how this pans out in context either....<br>
<blockquote cite="mid:hsarli$sfk$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">
Does this look absurd to you?
</pre>
</blockquote>
<pre wrap=""><!---->
Ok. I can see your use case.
</pre>
</blockquote>
I'm still doubtful.<br>
<blockquote cite="mid:hsarli$sfk$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">What about other things like EClass<T>? Much in the vein of Class<T>?
</pre>
</blockquote>
</blockquote>
At least this is simpler than the feature case, but I still argue its
utility is greatly limited. In the end, parameterizing the Ecore model
itself would have resulted in much more disruptive changes in all the
downstream usage, only a very very tiny portion of which would have
derived any real value from it. Look how quickly your example above
degrades into using ? all over the place.<br>
<blockquote cite="mid:hsarli$sfk$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">JFace-Viewers can't use generics because it is constrainted to Java 1.3.
</pre>
</blockquote>
<pre wrap="">Ouch! Is this going to change some day, soon? I understand that legacy
environment have to be supported, but it is too bad that it is at such a
cost for developers who can use Java 5 or 6.
</pre>
</blockquote>
<pre wrap=""><!---->
No. I started on working for this in e4 but didn't had time to implement
it fully. The viewers in UFaceKit are generified but they have not the
same featureset JFace-Viewers have today.
</pre>
<blockquote type="cite">
<pre wrap="">Has no effort been made to introduce more generics into JFace
databinding? IObservableValue, IObservableList & co. are just begging
for a parametrized version... :-) I'd gladly invest some time in this.
</pre>
</blockquote>
<pre wrap=""><!---->
Same applies to databinding. We try to keep the level very low (think
about embedded systems).
Tom
</pre>
</blockquote>
</body>
</html>
--------------000707020105040408090401--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: More generics in EMF/JFace [message #532968 is a reply to message #532860] |
Tue, 11 May 2010 16:58 |
J.-P. Pellet
Messages: 71
Registered: July 2009 |
Member |
|
|
>>> public class EMFColumnData<D,T> {
>>>
>>> public final EStructuralFeature<D,T> feature;
>>> public final IColumnLabelProvider<D,T> labelProvider;
>>>
>>> public EMFColumnData( EStructuralFeature<D,T> feature,
>>> IColumnLabelProvider<D,T> labelProvider ) {
>>> this.feature = feature;
>>> this.labelProvider = labelProvider;
>>> }
>>>
>>> public interface IColumnLabelProvider<D,T> {
>>>
>>> String getText( D element, T feature );
>>>
>>> }
>>> }
>>>
> What actually interesting things can you do knowing D and T? They're
> completely unconstrained so generically you can only assume
> java.lang.Object as possible substitutions.
Actually this is quite useful. If I create a EMFColumnData<ModelObject,
String>, then I can sure that I pass a compatible EStructuralFeature,
and that my IColumnLabelProvider gets a ModelObject and a String
directly, without the need to dangerously cast two Objects. If I
copy-paste my EMFColumnData and change the feature to something else
that's incompatible with the label provider, I get a compile-time error.
>>> void someMethod( EStructuralFeature<? extends BaseClass, ?> feature );
>>>
> I'm not sure how this pans out in context either....
Suppose I have a method in some utility class setupTableViewer() that
sets up a viewer to work with all objects derived from some BaseClass
(which, say, all have a name and a timestamp in common). If I want to
pass additional features to this method (say, to create additional
columns), I would like to make sure that they are applicable to
BaseClass, hence this parametrization: EStructuralFeature<? extends
BaseClass, ?>.
> At least this is simpler than the feature case, but I still argue its
> utility is greatly limited. In the end, parameterizing the Ecore model
> itself would have resulted in much more disruptive changes in all the
> downstream usage, only a very very tiny portion of which would have
> derived any real value from it. Look how quickly your example above
> degrades into using ? all over the place.
I agree that there are too many "?". We could imagine that the
EStructualFeature interface remains parameterless, which can be used as
before by everyone, but that the literals are typed something like
EStructualFeatureX<D,T>, where EStructualFeatureX extends
EStructualFeature. Same with EClass/EClassX<T>. This makes more type
information available with minimal changes to the public interface and
no require change to user code.
A workaround that I'm implementing now is to extend
org.eclipse.emf.codegen.ecore.generatorAdapters with my own generator. I
am creating an extra package interface named "<modelname>PackageX" that
holds parametrized literals of the type EClassX<T>, etc. These
"extended" literals do nothing but provide the extra type information
and wrap the standard literals.
Best,
J.-P.
|
|
|
| Re: More generics in EMF/JFace [message #532969 is a reply to message #532968] |
Tue, 11 May 2010 17:22 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
J.-P.,
Comments below.
J.-P. Pellet wrote:
>>>> public class EMFColumnData<D,T> {
>>>>
>>>> public final EStructuralFeature<D,T> feature;
>>>> public final IColumnLabelProvider<D,T> labelProvider;
>>>>
>>>> public EMFColumnData( EStructuralFeature<D,T> feature,
>>>> IColumnLabelProvider<D,T> labelProvider ) {
>>>> this.feature = feature;
>>>> this.labelProvider = labelProvider;
>>>> }
>>>>
>>>> public interface IColumnLabelProvider<D,T> {
>>>>
>>>> String getText( D element, T feature );
>>>>
>>>> }
>>>> }
>>>>
>> What actually interesting things can you do knowing D and T? They're
>> completely unconstrained so generically you can only assume
>> java.lang.Object as possible substitutions.
>
> Actually this is quite useful. If I create a
> EMFColumnData<ModelObject, String>, then I can sure that I pass a
> compatible EStructuralFeature, and that my IColumnLabelProvider gets a
> ModelObject and a String directly, without the need to dangerously
> cast two Objects. If I copy-paste my EMFColumnData and change the
> feature to something else that's incompatible with the label provider,
> I get a compile-time error.
What I'm wondering about is how you'd actually do anything interesting
to implement the getText method. Of course JFace itself doesn't provide
any of this generic stuff either...
>
>>>> void someMethod( EStructuralFeature<? extends BaseClass, ?> feature );
>>>>
>> I'm not sure how this pans out in context either....
>
> Suppose I have a method in some utility class setupTableViewer() that
> sets up a viewer to work with all objects derived from some BaseClass
> (which, say, all have a name and a timestamp in common). If I want to
> pass additional features to this method (say, to create additional
> columns), I would like to make sure that they are applicable to
> BaseClass, hence this parametrization: EStructuralFeature<? extends
> BaseClass, ?>.
It's clear one can come up with examples that are relatively interesting
but how generally useful such things will be isn't as clear.
>
>> At least this is simpler than the feature case, but I still argue its
>> utility is greatly limited. In the end, parameterizing the Ecore
>> model itself would have resulted in much more disruptive changes in
>> all the downstream usage, only a very very tiny portion of which
>> would have derived any real value from it. Look how quickly your
>> example above degrades into using ? all over the place.
>
> I agree that there are too many "?". We could imagine that the
> EStructualFeature interface remains parameterless, which can be used
> as before by everyone, but that the literals are typed something like
> EStructualFeatureX<D,T>, where EStructualFeatureX extends
> EStructualFeature. Same with EClass/EClassX<T>. This makes more type
> information available with minimal changes to the public interface and
> no require change to user code.
People already complain that EMF is too complex, so adding more
complexity with very significant added value isn't at all appealing.
>
> A workaround that I'm implementing now is to extend
> org.eclipse.emf.codegen.ecore.generatorAdapters with my own generator.
> I am creating an extra package interface named "<modelname>PackageX"
> that holds parametrized literals of the type EClassX<T>, etc. These
> "extended" literals do nothing but provide the extra type information
> and wrap the standard literals.
Maybe you'll want to write an interesting article about it. That would
be cool...
>
> Best,
> J.-P.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:12:21 GMT 2024
Powered by FUDForum. Page generated in 0.03779 seconds |
] 
Search
Help
Register
Login
Home
