Home » Modeling » EMF » Type parameters of iterator classes of BasicEList
|
| Re: Type parameters of iterator classes of BasicEList [message #421585 is a reply to message #421584] |
Mon, 11 August 2008 00:28   |
 Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050104060702030304000505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reinhold,
You mean the E1 here:
public class BasicEList<E> extends AbstractList<E> implements
EList<E>, RandomAccess, Cloneable, Serializable
{
//....
/**
* An extensible iterator implementation.
*/
protected class EIterator<E1> implements Iterator<E1>
{
It's a very good question. I'm not absolutely sure this was done
correctly. It may well be more general than it should be.
BasicFeatureMap has some tricky/surprising uses of it though. Is this
approach causing problems in the translation?
Reinhold Bihler wrote:
> Hello,
>
> while trying to translate BasicEList using the iLog Java to C# translator
> Alexandre and I encountered a comprehension problem: Why is the type
> parameter of the iterator classes of BasicEList e.g. class
> NonResolvingEListIterator<E1> different for the type parameter of class
> BasicEList<E>?
> The iterators always seem to be constructed with the type parameter "E" of
> BasicEList.
>
> Is this to allow the creation of iterators of supertypes of type E? Even
> though this possibility is never used in the code?
>
> However, as such a constraint is nowhere expressed isn't it possible to
> construct an iterator with a subtype of E or a type that is totaly unrelated
> to E? Wouldn't that cause runtime (cast) exceptions?
>
> Regards,
>
> Reinhold
>
>
>
>
>
--------------050104060702030304000505
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">
Reinhold,<br>
<br>
You mean the E1 here:<small><br>
</small>
<blockquote><small>public class BasicEList<E> extends
AbstractList<E> implements EList<E>, RandomAccess,
Cloneable, Serializable </small><br>
<small>{</small><br>
<br>
<small> //....</small><br>
<br>
<small> /**</small><br>
<small> * An extensible iterator implementation.</small><br>
<small> */</small><br>
<small> protected class EIterator<E1> implements
Iterator<E1></small><br>
<small> {</small><br>
</blockquote>
It's a very good question. I'm not absolutely sure this was done
correctly. It may well be more general than it should be.
BasicFeatureMap has some tricky/surprising uses of it though. Is this
approach causing problems in the translation?<br>
<br>
<br>
Reinhold Bihler wrote:
<blockquote cite="mid:g7nt4c$5g9$1@build.eclipse.org" type="cite">
<pre wrap="">Hello,
while trying to translate BasicEList using the iLog Java to C# translator
Alexandre and I encountered a comprehension problem: Why is the type
parameter of the iterator classes of BasicEList e.g. class
NonResolvingEListIterator<E1> different for the type parameter of class
BasicEList<E>?
The iterators always seem to be constructed with the type parameter "E" of
BasicEList.
Is this to allow the creation of iterators of supertypes of type E? Even
though this possibility is never used in the code?
However, as such a constraint is nowhere expressed isn't it possible to
construct an iterator with a subtype of E or a type that is totaly unrelated
to E? Wouldn't that cause runtime (cast) exceptions?
Regards,
Reinhold
</pre>
</blockquote>
</body>
</html>
--------------050104060702030304000505--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Type parameters of iterator classes of BasicEList [message #421752 is a reply to message #421585] |
Tue, 12 August 2008 22:48 |
Reinhold Bihler
Messages: 64
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01C8FCDE.44FFE760
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
yes, I was refering to e.g. EIterator<E1>. I had (and probably still =
have) to do more research on this. The translation of this makes some =
problems for several reasons. First C# has no (non-static) inner classes =
like e.g. EIterator<E1> that allow to access members of the outer class =
object (in this case a BasicEList<E> object). Therefore in C# the outer =
class object must be passed in the constructor of the inner class (what =
is the same that is happening in Java behind the scenes). So =
EIterator<E1> is translated to something like this:
public class BasicEList<E> : IList<E> , EList<E>, ICloneable
{ ...
public override IIterator<E> iterator()
{
return new BasicEList<E>.EIterator(this);
}
public class EIterator<E1> : IIterator<E1>
{
private BasicEList<E> outer_BasicEList;
public EIterator(BasicEList<E> basicEList)
{
outer_BasicEList =3D basicEList;
....
Second issue: In Java it seems that it makes no difference what name you =
give to the type parameter of the inner class. The type parameter of the =
outer class is always considered different by the compiler. So even if =
you write the following in Java:
public class BasicEList<E> extends AbstractList<E> implements EList<E>, =
RandomAccess, Cloneable, Serializable=20
{
protected class EIterator<E> implements Iterator<E>
{
// E is a different type than the E of BasicEList here.
}
However, in some cases it seem to be possible in Java to refer to the =
outer class parameter type in the inner class (as it is done in the =
EIterator implementation). But I am still not sure about what rules =
apply here. Does somebody know more details on this? Or knows a good =
documentation that explains this?
And there is a bug in the Eclipse Java refactoring mecanism in such =
strange constellations (see here: =
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D243185) on which the =
iLog translator relies and which is oben since 4 years.
But Alexandre is working on a workaround for this. So there are problems =
but there is also light ;-)
The translator works great on not too compicated code. And for too =
complicated code I have to find a C# way and do the translation by hand.
Reinhold
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:g7o14f$dpg$1@build.eclipse.org...
Reinhold,
You mean the E1 here:
public class BasicEList<E> extends AbstractList<E> implements =
EList<E>, RandomAccess, Cloneable, Serializable=20
{
//....
/**
* An extensible iterator implementation.
*/
protected class EIterator<E1> implements Iterator<E1>
{
It's a very good question. I'm not absolutely sure this was done =
correctly. It may well be more general than it should be. =
BasicFeatureMap has some tricky/surprising uses of it though. Is this =
approach causing problems in the translation?
Reinhold Bihler wrote:=20
Hello,
while trying to translate BasicEList using the iLog Java to C# =
translator=20
Alexandre and I encountered a comprehension problem: Why is the type=20
parameter of the iterator classes of BasicEList e.g. class=20
NonResolvingEListIterator<E1> different for the type parameter of class=20
BasicEList<E>?
The iterators always seem to be constructed with the type parameter "E" =
of=20
BasicEList.
Is this to allow the creation of iterators of supertypes of type E? Even =
though this possibility is never used in the code?
However, as such a constraint is nowhere expressed isn't it possible to=20
construct an iterator with a subtype of E or a type that is totaly =
unrelated=20
to E? Wouldn't that cause runtime (cast) exceptions?
Regards,
Reinhold
------=_NextPart_000_000A_01C8FCDE.44FFE760
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16674" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>yes, I was refering to e.g. <FONT=20
face=3D"Times New Roman">EIterator<E1>. </FONT></FONT><FONT =
face=3DArial=20
size=3D2>I had (and probably still have) to do more research on this. =
The=20
translation of this makes some problems for several reasons. =
</FONT><FONT=20
face=3DArial size=3D2>First C# has no (non-static) inner classes =
like e.g.=20
EIterator<E1> that allow to access members of the outer class =
object (in=20
this case a BasicEList<E> object). Therefore in C# the outer class =
object=20
must be passed in the constructor of the inner class (what is the same =
that is=20
happening in Java behind the scenes). So EIterator<E1> is =
translated to=20
something like this:</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT color=3D#0000ff size=3D2>public</FONT><FONT =
size=3D2> </FONT><FONT=20
color=3D#0000ff size=3D2>class</FONT><FONT size=3D2> </FONT><FONT =
color=3D#008080=20
size=3D2>BasicEList</FONT><FONT size=3D2><E> : </FONT><FONT =
color=3D#008080=20
size=3D2>IList</FONT><FONT size=3D2><E> , </FONT><FONT =
color=3D#008080=20
size=3D2>EList</FONT><FONT size=3D2><E>, </FONT><FONT =
color=3D#008080=20
size=3D2>ICloneable</FONT></DIV>
<DIV><FONT color=3D#008080 size=3D2>{ ...</FONT></DIV>
<DIV><FONT color=3D#008080 size=3D2><FONT color=3D#0000ff size=3D2><FONT =
color=3D#0000ff=20
size=3D2></FONT></FONT></FONT> </DIV>
<DIV><FONT color=3D#008080 size=3D2><FONT color=3D#0000ff size=3D2><FONT =
color=3D#0000ff=20
size=3D2> public</FONT><FONT size=3D2> </FONT><FONT =
color=3D#0000ff=20
size=3D2>override</FONT><FONT size=3D2> </FONT><FONT color=3D#008080=20
size=3D2>IIterator</FONT><FONT size=3D2><E>=20
iterator()</FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#008080><FONT color=3D#0000ff><FONT =
size=3D2> =20
{<BR> <FONT=20
color=3D#0000ff>return</FONT> <FONT color=3D#0000ff>new</FONT> <FONT=20
color=3D#008080>BasicEList</FONT><E>.EIterator( <FONT=20
color=3D#0000ff>this</FONT>);<BR> }</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000></FONT><BR><FONT =
size=3D2> =20
public</FONT></FONT><FONT size=3D2><FONT color=3D#000000> </FONT><FONT=20
color=3D#0000ff>class</FONT><FONT color=3D#000000> </FONT><FONT=20
color=3D#008080>EIterator</FONT><FONT color=3D#000000><E1> : =
</FONT><FONT=20
color=3D#008080>IIterator</FONT></FONT><FONT size=3D2><FONT=20
color=3D#000000><E1><BR></FONT> =20
{<BR> <FONT color=3D#0000ff> =
</FONT><FONT=20
color=3D#0000ff>private</FONT> <FONT =
color=3D#008080>BasicEList</FONT><E>=20
outer_BasicEList;</FONT></DIV>
<P><FONT size=3D2></FONT></P>
<DIV><FONT size=3D2><FONT=20
color=3D#0000ff> =
</FONT><FONT=20
color=3D#0000ff>public EIterator(BasicEList</FONT></FONT><FONT =
size=3D2><FONT=20
color=3D#0000ff><E>=20
basicEList)<BR> </FONT><FONT=20
color=3D#0000ff>{</FONT></FONT></DIV>
<DIV><FONT color=3D#0000ff=20
size=3D2> &nbs=
p;=20
outer_BasicEList =3D basicEList;</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>...</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff><FONT color=3D#000000 =
size=3D2>Second=20
issue: In Java it seems that it makes no difference what name you =
give to=20
the type parameter of the inner class. The type parameter of the outer =
class is=20
always considered different by the compiler. So even if you write the =
following=20
in Java:</FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2></FONT> </DIV>
<DIV>
<DIV><SMALL>public class BasicEList<E> extends =
AbstractList<E>=20
implements EList<E>, RandomAccess, Cloneable, Serializable=20
</SMALL><BR><SMALL>{</SMALL><BR></DIV>
<DIV><SMALL> protected class EIterator<E> implements=20
Iterator<E></SMALL><BR><SMALL> {</SMALL></DIV></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2> // E =
is a=20
different type than the E of BasicEList here.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2> }</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2>However, in some cases =
it seem to be=20
possible in Java to refer to the outer class parameter type in the inner =
class=20
(as it is done in the EIterator implementation). But I am still not sure =
about=20
what rules apply here. Does somebody know more details on this? Or knows =
a good=20
documentation that explains this?</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2>And there is a bug in =
the Eclipse=20
Java refactoring mecanism in such strange constellations (see here: <A=20
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D243185">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D243185</A>)=20
on which the iLog translator relies and which is oben since 4=20
years.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2>But Alexandre is =
working on a=20
workaround for this. So there are problems but there is also light=20
;-)</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2>The translator works =
great on not too=20
compicated code. And for too complicated code I have to find a C# way =
and do the=20
translation by hand.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#000000 =
size=3D2>Reinhold</FONT></DIV></FONT><FONT=20
face=3DArial size=3D2></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:g7o14f$dpg$1@build.eclipse.org">news:g7o14f$dpg$1@build.ecli=
pse.org</A>...</DIV>Reinhold,<BR><BR>You=20
mean the E1 here:<SMALL><BR></SMALL>
<BLOCKQUOTE>
<DIV><SMALL>public class BasicEList<E> extends =
AbstractList<E>=20
implements EList<E>, RandomAccess, Cloneable, Serializable=20
</SMALL><BR><SMALL>{</SMALL><BR><BR><SMALL> =20
//....</SMALL><BR><BR><SMALL> =
/**</SMALL><BR><SMALL> * An=20
extensible iterator implementation.</SMALL><BR><SMALL> =20
*/</SMALL><BR><SMALL> protected class EIterator<E1> =
implements=20
Iterator<E1></SMALL><BR><SMALL> =
{</SMALL></DIV></BLOCKQUOTE>It's a=20
very good question. I'm not absolutely sure this was done=20
correctly. It may well be more general than it should be. =20
BasicFeatureMap has some tricky/surprising uses of it though. Is =
this=20
approach causing problems in the translation?<BR><BR><BR>Reinhold =
Bihler=20
wrote:=20
<BLOCKQUOTE cite=3Dmid:g7nt4c$5g9$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hello,
while trying to translate BasicEList using the iLog Java to C# =
translator=20
Alexandre and I encountered a comprehension problem: Why is the type=20
parameter of the iterator classes of BasicEList e.g. class=20
NonResolvingEListIterator<E1> different for the type parameter of =
class=20
BasicEList<E>?
The iterators always seem to be constructed with the type parameter "E" =
of=20
BasicEList.
Is this to allow the creation of iterators of supertypes of type E? Even =
though this possibility is never used in the code?
However, as such a constraint is nowhere expressed isn't it possible to=20
construct an iterator with a subtype of E or a type that is totaly =
unrelated=20
to E? Wouldn't that cause runtime (cast) exceptions?
Regards,
Reinhold
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000A_01C8FCDE.44FFE760--
|
|
|
| Re: Type parameters of iterator classes of BasicEList [message #421771 is a reply to message #421752] |
Wed, 13 August 2008 12:41 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Reinhold,
One comment about Java generics, below.
HTH,
Christian
Reinhold Bihler wrote:
> Second issue: In Java it seems that it makes no difference what name you
> give to the type parameter of the inner class. The type parameter of the
> outer class is always considered different by the compiler. So even if
> you write the following in Java:
>
> public class BasicEList<E> extends AbstractList<E> implements EList<E>,
> RandomAccess, Cloneable, Serializable
> {
> protected class EIterator<E> implements Iterator<E>
> {
> // E is a different type than the E of BasicEList here.
> }
>
> However, in some cases it seem to be possible in Java to refer to the
> outer class parameter type in the inner class (as it is done in the
> EIterator implementation). But I am still not sure about what rules
> apply here. Does somebody know more details on this? Or knows a good
> documentation that explains this?
Actually, in Java, inner classes behave like members in some respects.
As they have visibility of the proper members (fields, methods) of the
outer class, so do they have visibility of its type parameters to bind
them to their own type parameters (substituting their parameters with
the outer class's).
So, BasicEList could have been declared thus:
public class BasicEList<E> extends extends AbstractList<E>
implements EList<E>, Serializable {
// ...
protected class EIterator implements Iterator<E> { ... }
// ...
}
And that would bind all of the occurrences of E in the Iterator
interface to the BasicEList's binding of E.
If the inner class had been declared thus:
protected class EIterator<E> implements Iterator<E> { ... }
then it would declare a *new* E parameter that shadows the outer class's
E. JDT compiler flags this for you.
|
|
|
| Re: Type parameters of iterator classes of BasicEList [message #421777 is a reply to message #421771] |
Wed, 13 August 2008 12:54 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Christian,
When Reinhold asked his question, I looked at changing it to be exactly
how you pointed out (don't introduce a new E or E1) and that would also
work, but then the use of this in BasicFeatureMap to implement an
iterator that iterates over the feature map entries but yields the value
of each one doesn't work...
Christian W. Damus wrote:
> Hi, Reinhold,
>
> One comment about Java generics, below.
>
> HTH,
>
> Christian
>
> Reinhold Bihler wrote:
>> Second issue: In Java it seems that it makes no difference what name
>> you give to the type parameter of the inner class. The type parameter
>> of the outer class is always considered different by the compiler. So
>> even if you write the following in Java:
>>
>> public class BasicEList<E> extends AbstractList<E> implements
>> EList<E>, RandomAccess, Cloneable, Serializable
>> {
>> protected class EIterator<E> implements Iterator<E>
>> {
>> // E is a different type than the E of BasicEList here.
>> }
>>
>> However, in some cases it seem to be possible in Java to refer to the
>> outer class parameter type in the inner class (as it is done in the
>> EIterator implementation). But I am still not sure about what rules
>> apply here. Does somebody know more details on this? Or knows a good
>> documentation that explains this?
>
> Actually, in Java, inner classes behave like members in some respects.
> As they have visibility of the proper members (fields, methods) of the
> outer class, so do they have visibility of its type parameters to bind
> them to their own type parameters (substituting their parameters with
> the outer class's).
>
> So, BasicEList could have been declared thus:
>
> public class BasicEList<E> extends extends AbstractList<E>
> implements EList<E>, Serializable {
>
> // ...
>
> protected class EIterator implements Iterator<E> { ... }
>
> // ...
> }
>
> And that would bind all of the occurrences of E in the Iterator
> interface to the BasicEList's binding of E.
>
> If the inner class had been declared thus:
>
> protected class EIterator<E> implements Iterator<E> { ... }
>
> then it would declare a *new* E parameter that shadows the outer
> class's E. JDT compiler flags this for you.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Type parameters of iterator classes of BasicEList [message #421787 is a reply to message #421777] |
Wed, 13 August 2008 14:25 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Ed,
Yes, I was careful not to suggest that anything change in the BasicEList
:-) Not that I was aware of the BasicFeatureMap dependency ...
It certainly make sense that the EIterator be reusable in
specializations of the BasicEList that need to provide iterators of a
different element type.
Good to know that EMF is correct, as usual!
cW
Ed Merks wrote:
> Christian,
>
> When Reinhold asked his question, I looked at changing it to be exactly
> how you pointed out (don't introduce a new E or E1) and that would also
> work, but then the use of this in BasicFeatureMap to implement an
> iterator that iterates over the feature map entries but yields the value
> of each one doesn't work...
-----8<-----
|
|
|
Goto Forum:
Current Time: Wed Sep 25 08:59:20 GMT 2024
Powered by FUDForum. Page generated in 0.04966 seconds |
] 
Search
Help
Register
Login
Home
