Home » Modeling » EMF » taking advantage of Java 5.0's support for covariant return types.
| taking advantage of Java 5.0's support for covariant return types. [message #414723] |
Tue, 20 November 2007 06:35  |
Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------040806060903000402090203
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi, Ed.
I read the below post of Marco Pantel and your answer in the ocl group.
As you suggested, I move the discussion to the EMF group.
I would be interested in the example you give, and get it running.
Thus I have a superclass Super, and three subclasses Sub1, Sub2, Sub3.
Then I have ref1, ref2, ref3 from Super to Sub1, Sub2, Sub3, and every
subclass has a reference op1, op2, op3 to the superclass, being the
opposite of its counterpart.
(see screenshot and ecore file)
Now, what do you mean by "provide EOperations in the base that have the
same matching signature as the feature accessors"
Sorry for not getting it immediatly, and thanks for an aditional hint in
advance.
Best, Philipp
Ed Merks wrote:
> Marco,
>
> This doesn't really sound like an OCL question. Opposites must be
> properly paired. You could define "container" to be a derived volatile
> unchangeable reference in the base and implement it by reusing
> EObject.eContainer(), which is the implicit opposite of all containment
> references; the subclass references would then be unidirectional. Or
> you could define three separate bidirectional references in the derived
> classes and provide EOperations in the base that have the same matching
> signature as the feature accessors, taking advantage of Java 5.0's
> support for covariant return types.
>
>
> Marco Pantel wrote:
>> Hi everyone!
>>
>> I have an abstract superclass and three subclasses of it.
>> Each of the subclasses has got two EReferences to the superclass.
>> I declared an EReference "container : superclass" in the superclass.
>> But now the ecore-editor won't let me choose this container-reference as
>> an EOpposite to one of the subclasses' references. It says "The opposite
>> must be a feature of the reference's type".
>>
>> How can I solve this problem?
>> Do I have to declare three different types of container-references, one
>> for each subclass?
>>
>>
>> Regards, Marco
>>
--------------040806060903000402090203
Content-Type: image/jpeg;
name="CovariantScreenshot.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="CovariantScreenshot.jpg"
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAIBAQEBAQIBAQECAgICAgQDAgIC AgUEBAMEBgUG
BgYFBgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgr/2wBDAQICAgIC AgUDAwUKBwYH
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgr/wAAR
CADbAggDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9/KKKKACiiigAooooAKKK KACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAor4EvPhHb/H79sL9o28+IXxj+MEMXhr4 qaXo+gab4W+O
virQbCwsj4L8M3hiitNM1K3gXdc3lzKzBNzNMxJPGNz/AIYl+GH/AEWP9oD/ AMSn8ff/AC6r
0qWVYitTU4tWfr/keVWzfDUKrpyTuvT/ADPt+iviD/hiX4Yf9Fj/AGgP/Ep/ H3/y6o/4Yl+G
H/RY/wBoD/xKfx9/8uq1/sbFd4/j/kZf25hP5Zfcv8z7for4g/4Yl+GH/RY/ 2gP/ABKfx9/8
uqP+GJfhh/0WP9oD/wASn8ff/Lqj+xsV3j+P+Qf25hP5Zfcv8z7for86/iv8 Hv2ePhHdWWi6
v8Xv2j9T1rU1Z9N8PaH+054+uL25RSA8gT+3AqIuRl3ZVzwCSQKofDH4d/s6 /ErxO3gOf4mf
tM+G/EQtmuYtA8UftM+PLa5ngXbuki2a66SBdw3BXLLkEgAgnjeFhHE/V3Vh z9ru/wCRP+sG
BTtZ/h/nv5H6R0V+e3xd+Bv7NvwN8NweKPiH8df2jUjvL5bLTdP0b9oz4k6p qOo3LI8nkWlj
Y6rNc3cixRTTMkMbskME0rBY4pHWj8Gvhd+y98eP7St/AXxt/abt77SPJbUt F8V/Hj4o6BqU
EU28Q3BstU1K3uPs8rRTpHcCPypHt50V2aGVU6v7IxHNbmjf1f8Akaf21huX m5JW9F/mfovR
XxB/wxL8MP8Aosf7QH/iU/j7/wCXVH/DEvww/wCix/tAf+JT+Pv/AJdVX9jY rvH8f8if7cwn
8svuX+Z9v0V8Qf8ADEvww/6LH+0B/wCJT+Pv/l1R/wAMS/DD/osf7QH/AIlP 4+/+XVH9jYrv
H8f8g/tzCfyy+5f5n2/RXxB/wxL8MP8Aosf7QH/iU/j7/wCXVH/DEvww/wCi x/tAf+JT+Pv/
AJdUf2Niu8fx/wAg/tzCfyy+5f5n2/RXxB/wxL8MP+ix/tAf+JT+Pv8A5dUf 8MS/DD/osf7Q
H/iU/j7/AOXVH9jYrvH8f8g/tzCfyy+5f5n2/RX5mft0fs26J8HP2JfjF8Xf hx8fP2gNO8Re
FfhX4h1jQdQ/4af8czfZb22024mgl8uXWGR9siK211ZTjBBBIr9M64sVhKmE klNrXsd+ExlL
GRcoJq3cKKKK5TrCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig D4w+EX/J2n7V
P/ZcNL/9QDwjXp9fPFxoH7SWuftaftL/APDPfxY8D+F/K+OFj/a//CZ/D281 77TnwB4N8ryf
s2raf5G3Em7d5u/emNmw79j/AIQH/gpH/wBHX/A//wAR81j/AOayvrsFKSwk Pde3l/mfF5hC
Lxs25Ja+f+R7fRXiH/CA/wDBSP8A6Ov+B/8A4j5rH/zWUf8ACA/8FI/+jr/g f/4j5rH/AM1l
dXPL+V/h/mcfJH+Zfj/ke30V4h/wgP8AwUj/AOjr/gf/AOI+ax/81lH/AAgP /BSP/o6/4H/+
I+ax/wDNZRzy/lf4f5hyR/mX4/5HMP498Q/Db9tv4q6PqfjTSPDWt+LfhjFH 8JvEHiEhLeG7
WJU8oTNlYx5wnJ6bS+T/AKxd3m11qf7VniT44/BXwz8Vf2gvDHjLxJb6211d 6b4eSO7uNEso
pd03n30LssnmW5lHLHAfZnLgN6T8Uv2Xf21fjTokfh/4n/H74DatbwSeZbGX 9n3Wklt36Fop
Y/FqyREjglGGRkHIOKp/Cf8AY9/a++B4uX+F/wAdPgNpk14At1eH4A67PcSI DkIZpvFzybAe
Qm7aCSQMk18hW4exVXMnVv7jlzb6781rXs9dE77dDCVGpKPs/ae7e+8lu1La 1n5PoumiZ2f7
c+o/CHQfCngvxR8X/iRrnw/h0zxwJtF+Kukz6fDb+Cb1tK1GH7dezanHLZRW 88Etxpga4hmU
z6pboirM8UsfgOpftG3/AIl8E+M/FPw++OPhX4h6b4P8VfC6bU/2hvh2kFst 34ej8Xh9T0rV
7yxmktpJNO02O6vr+WNra1W212RzZWcLEze/f8ID/wAFI/8Ao6/4H/8AiPms f/NZR/wgP/BS
P/o6/wCB/wD4j5rH/wA1lfUyjOUrpNfd2t3O6EqcYpNp/f3v/L/wPI+V/iR+ 1NoPxH8c3vih
/wBqLxxofwu1D9sOPRrvxJ4b1W/tIj4bHwmW7lSOYITb6PLdB7xr+HZDHFK2 pwXMO2O+Q+JH
xp8V6X8FL0/CL4z/ANufBJP2i49J0/x34k+Oeq6Vpc/hM+C1vJHk8bQ/a76K 3HigvbrdLM5a
5VdLMixMYF9++IX7Mn7f/wASfFvgXxnrv7Xvwdiuvh94qm1/Ro7T4Aaqsc1z JpOoaWyTBvFT
Fo/I1KdgFKN5iRncVDK3Vf8ACA/8FI/+jr/gf/4j5rH/AM1lZ+zqtu6e/l/n t5GvtaKtZrbz
/wDkd/M+Zfhlq3xP+Knhf4WeB4P2k76Lwd4q/aZvtL0q/wDhb8YdY8Rxz+HE 8Aard3OmL4n1
C0gudWjk1K3u3a5iaR7ORxBb3MFxp8f2X9Ca8Q/4QH/gpH/0df8AA/8A8R81 j/5rKP8AhAf+
Ckf/AEdf8D//ABHzWP8A5rK2pKVNO6b+7/MwquFRr3kvv/yPb6K8Q/4QH/gp H/0df8D/APxH
zWP/AJrKP+EB/wCCkf8A0df8D/8AxHzWP/msrTnl/K/w/wAzLkj/ADL8f8j2 +ivEP+EB/wCC
kf8A0df8D/8AxHzWP/mso/4QH/gpH/0df8D/APxHzWP/AJrKOeX8r/D/ADDk j/Mvx/yD/gpr
/wAo3P2g/wDsh/iz/wBM91X3fX5eft3eEf229L/YP+O998Xf2g/hXrnh1Pgf 4w/tDS/Dfwd1
LSr2fOh3oj8u6m8Q3aRYkKM26B9yqyjaWDr+odeBnLbqQuraH0mRpKlOzvqF FFFeMe4FFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH58XHxY8efDD9rT9pf8A 4Qj9mTxx8Rvt
3xwsftX/AAhl/oUH9n7PAHg3b539ranZbvM3tt8rzMeU+/ZlN2x/w1f8ef8A pGV8cP8Awf8A
gX/5pa6D4Rf8naftU/8AZcNL/wDUA8I16fX12CjJ4SHvPby/yPi8wnFY2acU 9fP/ADPEP+Gr
/jz/ANIyvjh/4P8AwL/80tH/AA1f8ef+kZXxw/8AB/4F/wDmlr2+iurkl/M/ w/yOPnj/ACr8
f8zxD/hq/wCPP/SMr44f+D/wL/8ANLR/w1f8ef8ApGV8cP8Awf8AgX/5pa9v oo5JfzP8P8g5
4/yr8f8AM8Q/4av+PP8A0jK+OH/g/wDAv/zS0f8ADV/x5/6RlfHD/wAH/gX/ AOaWvb6KOSX8
z/D/ACDnj/Kvx/zPEP8Ahq/48/8ASMr44f8Ag/8AAv8A80tH/DV/x5/6RlfH D/wf+Bf/AJpa
9voo5JfzP8P8g54/yr8f8zxD/hq/48/9Iyvjh/4P/Av/AM0tH/DV/wAef+kZ Xxw/8H/gX/5p
a9voo5JfzP8AD/IOeP8AKvx/zPEP+Gr/AI8/9Iyvjh/4P/Av/wA0tH/DV/x5 /wCkZXxw/wDB
/wCBf/mlr2+ijkl/M/w/yDnj/Kvx/wAzxD/hq/48/wDSMr44f+D/AMC//NLR /wANX/Hn/pGV
8cP/AAf+Bf8A5pa9voo5JfzP8P8AIOeP8q/H/M8Q/wCGr/jz/wBIyvjh/wCD /wAC/wDzS0f8
NX/Hn/pGV8cP/B/4F/8Amlr2+ijkl/M/w/yDnj/Kvx/zPjz9u79oP4t+OP2D /jv4W8T/ALC/
xU8G2N18D/GHn+JPEmr+E5bKz26HeuvmLp+uXNwd7KI18uF/mdS21dzr+odf CH/BTX/lG5+0
H/2Q/wAWf+me6r7vrwM5TVSF3fQ+kyNp0p2VtQooorxj3AooooAKKKKACiii gAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAKKKKACiiigAooooA8f+KX/BPb9gX44+O774pfGv8AYe+D/jDxPqnlf2n4 j8U/DTStQv7v
y4khj824nt3kk2RRxxruY7VRVGAAKwP+HTv/AASy/wCkaf7P/wD4ZvQ//kWv f6KAPAP+HTv/
AASy/wCkaf7P/wD4ZvQ//kWj/h07/wAEsv8ApGn+z/8A+Gb0P/5Fr3+igDwD /h07/wAEsv8A
pGn+z/8A+Gb0P/5Fo/4dO/8ABLL/AKRp/s//APhm9D/+Ra9x8T+J/DXgnw1q PjPxn4hsdI0f
SLGa91bVtUu0t7aytokMks80shCRxoiszOxCqqkkgCvHP+FY/wDDaP8AxUn7 RXw8/wCLX/e8
MfCzxVpP/Id/uarrtnOv0e00uZf9G+W5u0+2+RBpXpYHAQxEHXxE/Z0Y6OVr tv8AljG8eaXW
10ktW0iJStotWeHeGP8AgmJ/wTX/AGrPEuneM/Bn/BPT4HaR8JtIvob3SdW0 v4TaNb3Pj65i
cSRTwyx2wePQ0dVZXUhtVZQQRpo/4m3sf/Dp3/gll/0jT/Z//wDDN6H/APIt e/0VnjsZDFTU
aUOSnHSMd3bq5Ssuact5SsuiiowjGEXGPLu7v+v6/wCCeAf8Onf+CWX/AEjT /Z//APDN6H/8
i145+03/AMExP+Ca+gfGv9nbStC/4J6fA6ytdb+Md9Za1bWnwm0aOO/tl8F+ J7lYJ1W2AljE
9vBKEbKiSCN8bkUj7irw79tP/imtf+CPxmvvn0vwV8cdL/tWCHm4l/tqw1Hw ta+UpwrbL7X7
OSTcy7YIp2Xe6pFJ6HDcI1c19k1dzp1oRXec6M4wS83NxS82iK11C/mvuur/ AIFH/h07/wAE
sv8ApGn+z/8A+Gb0P/5Fo/4dO/8ABLL/AKRp/s//APhm9D/+Ra9/orwTU+R/ jN/wRm/4J+az
/Zvj34M/sBfs/wBj4o8O+c1no+q/CrSk0XX7eXYZrC+jSzfyt/lIYr6ON57O RQ6rPA91ZXZ8
Gf2BP+CWXxK/tLwh4v8A+CV/7P8A4a8c+GvJTxb4Sk+E+h3H2Xzd/kXlrP8A Yk+2afceVKbe
7CJv8qWKWOC5t7q1g+uK4f4zfArSfi9/Zuuad411zwd4q0Pzl8P+OPChtRqW nRT7Bc24F5Bc
W09vOscfmW9xDLEXhgmCLPbW80XsYXE4TE0FhMWlFL4KlneF3e0kr81Ntu9k 5xvzQ5rOnPOS
knzR+7+uv4fmvOP+HTv/AASy/wCkaf7P/wD4ZvQ//kWj/h07/wAEsv8ApGn+ z/8A+Gb0P/5F
ruPhB8X/ABLfeJZ/gd8cbGx0z4gaZYteI+nRPHp3ijTkdIzq2miR3dYw8kSX Fo7vNYzTRxyP
NDPZ3l56PXDjMHWwNb2dT1TWqkntKL6p9H+uhUZKSujwD/h07/wSy/6Rp/s/ /wDhm9D/APkW
j/h07/wSy/6Rp/s//wDhm9D/APkWvf6K5SjwD/h07/wSy/6Rp/s//wDhm9D/ APkWvf6KKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPnL4K/tufEr4kXPwq8aeMv gXoei+Afjns/
4VjrGmeOZr/WD5+jXeuWv9qae+nQQ2W6wsbjzPIvLvy7gxRL5sbNcJR/Zt/b z+LPxk0P4M/E
b4mfsx2Pgzwn8dbG2XwVLD49Gp6tBfyaHdazi8tEs44IrN7awvDFPHdSzsGt PNtbd5p47Xqv
hN+wr4U+FGv+DnHxq8c6/wCF/hrn/hV/gLXDpQ03wptsJ9Ng+zzWthDfXPk6 fc3Non226udy
TGSTzJ1SZOH/AGCf2Ctf+DfwK+BifGv4l+ObzVPht4G0mSx+HWuazYXum+Fv ER0Q6fezW91F
AbyfC3epQpDLe3FnEl0VgiRIbUQfqOKfh9PBYupQhBNJKmr1+a8limnFOesl /s3tXOLppqfK
1eKnwx+tqUU367f3fL/Fbr+nVfsNxfETRfG/x88A/ET44eKvH8nhr4x21lpm t+L3sxcx20nh
Dw3d+Qsdjb21rDGst1MwSGCNSzs7BpHkkfc/bv8AE/iXwx+z9BH4X8Q32lya 98R/BXhzULzS
7t7a5Gnar4p0rTL6OGeMrLbyPaXdxGs8TJNEziSJ45ER17n4efCDw18NfF3j vxnoV9fS3XxC
8VQ+INaju5UaOG5j0nTtKVIAqKVj8jTIGIYu3mPIdwUqqnxq+EHhr46fDu5+ Hfii+vrON76x
1HT9T0uVFudN1GxvIb6xvYfMR4mkgu7e3nVJY5IXaILLHLGzxt8083y+rxVh cfOK9lF4dzSi
kvchTVS0ElG3NGVkkk+iN/ZyVCUVvr+tjzj9jGbVtD8UfGn4NN4p1zVND+H3 xVg0fwp/wkmv
3WrXttZT+F9A1SSKS+vZJbq6/wBL1G8dWnlkZFkWJSsUccaUf2m4viJoH7Wv 7O3iXQvjh4qs
tB1v4j32h614DtHs49Jv1Xwj4nvVuZytuLuWQS28GImuDbAwRv5Hmoso7j4Q fs6Q/B+Ge6sf
i54q1nWNZ8VN4g8beIdZTTftPiq5/s1NNiS7S3s4oII4ra3sFUWUVqxbT4Wd nMlz59/W/gVp
Piy5+GmreMvGuuatqnww1z+2NO1a5NrFLq16dGv9IklvEggSI74dSuJSsCQK JQhUKgMZ6Kma
5fDOquK54zUqMqbbjdyqPDypup70d5VV7Tndp++pO0udRnkm6ajtrf5Xvb7t LbHcVh/Ej4ke
C/hH4LvfiD8QdZ+w6XY+WskiW0k8s0ssiwwW8EEKtLc3E00kcMNvEryzSyxx Ro7uqk+JHxI8
F/CPwXe/EH4g6z9h0ux8tZJEtpJ5ZpZZFhgt4IIVaW5uJppI4YbeJXlmllji jR3dVPDfDf4b
+NPiJ40sv2g/2g9G+w6pY+Y3gTwI9zHPF4QiljaJ7id4maK51iaGR45riNni tYpZLO0d0e8v
NR+fwWCpSpPF4tuNGLtppKclZ8kLpq9mnObTjTi02pSlCE9pSd+WO/5f1+P3 tUfDHg34iftF
+JdO+JP7QXw+vvCXhvQb6G88KfC7V7yzubmTUYHDpq2rvZTz2sskMqh7K0im mhgZEvZXkuzb
R6X7HRRWOOx9THTXuqEI6RhG/LFeV23ru225Pq2OMVFBRRXK/CD47fBD9oPw 1P4z+Afxk8K+
ONHtb5rK51bwh4httTtorlUSRoGltndFkCSRsUJ3BZFOMMM88MPiKlGVaMG4 RspNJ2Td7Xey
vZ2vvZ2HdJ2Oqrw7/goV/wAkF0D/ALLj8Mf/AFO9Br2PxD4n8NeEbCPVfFfi Gx0u1lvrWyiu
dRu0gje5uZ47a2gDOQDJLPLFFGn3nkkRFBZgD45/wUK/5ILoH/Zcfhj/AOp3 oNe5wnCa4ny+
VtHXpK/S6nG/3XX3ozr/AMGXo/yPcaKKK+dNQooooA5X4v8AwV+Hfx08NQeF /iJpt88dnfLe
6ZqGja5eaVqOm3Ko8fn2l9Yyw3VpI0Us0LPDKjPDPNExaOWRG4bwx8cL/wCB viXTvgj+1d47
sYrrVL6Gw+H/AMRNUeCxtvGUkjiOGwmChIbfXAWUNaxqkd6ubmzRVF1Zad7H VHxP4Y8NeNvD
Wo+DPGfh6x1fR9XsZrLVtJ1S0S4tr22lQxywTRSApJG6MysjAqysQQQa9bB5 jBUfqmMTnQ3S
TtKDf2qbd0r/AG425Zre0ownDOUNeaOj/P1/rT7071ecftF/G7xL8IYfCPhr 4e+BbHxF4s8f
eKm8P+FdO1nXX0zTvtMem32qSvd3cVtdSwRi00262mO3mZpjChVEd5Y+V/4T 3xp+x9/xT3xZ
h1zxJ8Lbb95YfFC5v47m48IWQ4MHiB55hc3FvExjCatGs7CAvJqRh+xzaneX v2t/BvxE1HWP
hV8XPh38Pr7xbJ8M/iPN4g1Pwvo15ZwajqVtP4e1nSNlo19Pb2pkSXVIZmE0 8K+TDMVZ5BHF
J6WAynDUczp/WHGdCcajhJy5YTlGDcIzlzR5Hz8inGUoyipJtqMoycTqScHy 6PT8/wAdL2Or
/Z0+M3/C+vhZF49uPDf9j31vrmsaFrempefaYoNS0rU7rS71YJikZnt/tVnO YZWjieSIxu8U
LM0SYR/aT1+L9six/ZQ1D4G65p9jqHgbV/EWnePL/VLD7Fqf2C40aGSC1t4J 5bn5W1cCR7lL
ba0AEazrIZI8P9mHQ/in8CvgdcaT4n+C+uX2qatrnjnxsdJ0rUNMaWzbUvEV 5q9nosry3iRH
UHh1IRFo3eyWW0uA12E8mSbc8X/Dfxpqn7b3w8+L9jo3meHdD+FXjLR9V1H7 TGPIvb7UvDE9
rF5ZbzG3x6deNuVSq+ThipdA288Jk1HP8ZTtB4drEqk/aXtyRm6TTU7tuUYx jz8ympaKTaaS
lUdKL1v7t9PS/wDXQ9Voor4B/wCFS6B/wnH2H/hmrXP+Gkf+Gjf7W/4Wh/wq u/8AtH/CJf8A
Cc/bdn/CW/ZPsn2f/hEv9F+y/bc+R/xLfL8z/Ra5OH8hpZ37TnquHK4rSPNZ S5r1J+9Hko07
L2lTXk5o6alVarp20/rt6voj7+ryq0/as0n/AIXRp/wk8R/BvxzoNjr2uXmh +EvGuuafawab
r+q2ttc3M9pbw/aTqEeIbG/kS4uLSG1mSzLwzSLPatP8V/BvwD8O/Ed1eT/D /wDZs8VD41D9
rjXb3R/iXN4OvLqOPw5b/E+7l1dLPxAqy22kWZ02LVreXTXuLR7iR7vFrKdS SS8+jvHGoTfF
P9uD4aX/AIQ+F/xHste8FeKtSi8bnxPompDw9b+H10bWoYNQsZpd+jSXk95d 6btnsXOqra3U
1vN5USX1vH9PiODsDlWIxFGrKVTlhX1lFQcXSi3GolGpK9Oc7U4zldcylTcF NxccFiJVIprT
Vee/TbdLW3z2PpuiiivzQ7QooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuV +L/xf8NfBrw1
BrWtWN9qeoanfLp3hrw1o0SSajr2oujvHZWkbuiNIUjlkZ5HSGCGGa4nkhgg mmjo/Gb9ob4a
/A/+zdG8Sap9u8UeIvOj8GeBdKnhfWvE9xFs3w2NtJInm7PNjaWZmSC2jYz3 MsECSSrQ+EHw
g8S2PiWf44/HG+sdT+IGp2LWaJp0ryad4X053SQ6TppkRHaMvHE9xduiTX00 MckiQwwWdnZ+
xhcBTo0FjMamqb+GOzqNO1ov+VNWlLp8K97bOUm3yx3/ACKPw3+BXjTUvGll 8cP2kPGv9veK
LXzJ/D/haxMZ8P8AguWaNoZRp37iKe7uDbt5D6hdlpWD3X2aPT4L2ezPqtFF ceNx1fH1VOpZ
JK0UklGK1doxWiV22+rk3KTcm26jFQWgUUUVxlHh3/BTr/lGx+0L/wBkO8Wf +me6o8A/8pJ/
iz/2Q74e/wDp48aV7jXD+Av2Yv2a/hV4Lf4b/C/9nrwN4b8Oya5b61JoGgeE 7Ozsm1KCSCWC
9MEMaxm4jktrZ0mxvVreJgQY1I+owOd4Wjw9Vy6rGXNJys0k1ac8PKTd2tY/ V0ktebnd3Hl9
7GVOTqqa/rf/ADPKv+ClHwx+Gvir4c+AfiR4n+Hmh6l4i8KfHH4d/wDCL6/f 6TDNe6P9p8b6
BFc/ZZ3UyW/mxgJJ5ZXeoCtkDFbn/BRz/iV/sia98SLjmx+HWueH/H+txJzL Ppvh3XLDXb2G
AHhrh7XTp0hViiNK0au8alnX1X/hWPw1/sD/AIRX/hXmh/2X/bn9tf2b/ZMP 2f8AtL7f/aP2
3y9u37R9u/0vzsb/AD/3ud/zV5V/wU6/5RsftC/9kO8Wf+me6r0OHcz9vmeU 4C8mqWK5ot/y
znRskrvl1hKTSdry73ZFWFoTl3X5XPca+cvgr+258SviRc/Crxp4y+Beh6L4 B+Oez/hWOsaZ
45mv9YPn6Nd65a/2pp76dBDZbrCxuPM8i8u/LuDFEvmxs1wn0bXh3wm/YV8K fCjX/Bzj41eO
df8AC/w1z/wq/wABa4dKGm+FNthPpsH2ea1sIb658nT7m5tE+23VzuSYySeZ OqTJ5eSzyCOA
xSx8U6nL+7vz3T5Ki93kajze0dJv2nu8in1sndRVeePJt127r9L7HK/s2/t5 /Fn4yaH8GfiN
8TP2Y7HwZ4T+OtjbL4Klh8ejU9Wgv5NDutZxeWiWccEVm9tYXhinjupZ2DWn m2tu808dqfsl
eBvHfh/43vceGfjd4q8c6DpHhW90j4veLvEWvX1xp3ifxwlzZDztHs7m4uId NjtTFrCXVvYC
CzimvobRfPlsJorGj+wT+wVr/wAG/gV8DE+NfxL8c3mqfDbwNpMlj8Otc1mw vdN8LeIjoh0+
9mt7qKA3k+Fu9ShSGW9uLOJLorBEiQ2og9G/ZS/ZI1j9lDw1ovw90r9qv4j+ MPCfhrwrbeH/
AA74V8X2nh4W2n21ukMVu6y6fpNrdSSRxQiMGWZ1ZXYsrPtdfrc+xfC+Bq4+ hk9SnGD91QSq
yhUXPWs1KXtG5QpulZOapOp+8jKTpwkc9KNeSi6if4aaL0636Xtp1Z7HRRRX 5cdwV4d/YHxK
/Y9/c/CzwR/wlHwft/38/hfTppm1rwTbjh4tHtI4JP7U09dwlTTg8U9nHDND ZC8R7LTbb3Gi
vQwOPlg+anOCnSnbmg72dr2aas4yjd8slqruLvCU4yiUObVaMo+GPE/hrxt4 a07xn4M8Q2Or
6Pq9jDe6Tq2l3aXFte20qCSKeGWMlJI3RlZXUlWVgQSDV6vHPE/wg+InwV8S 6j8XP2ar6+v9
Pu76bUfEvwbeWzi07V5p3Ml7e6ZNKiPp+qSviYI066fczeeZo4J76bVIvR/h v8SPBfxc8F2X
xB+H2s/btLvvMWOR7aSCWGWKRoZ7eeCZVltriGaOSGa3lVJYZYpIpER0ZRpj cBTpUlicNPno
t2v1hJ3ahNdJWTaavGaUuVtxnGJGbb5ZaP8ArY3KKKK8ssw/h78N/Bfwq0C4 8MeAtG+wWN1r
mqaxPB9pkl3Xuo38+oXku6RmI8y6uZ5NoO1d+1AqhVG5RRWlarVxFWVWrJyl Jttt3bb1bber
berbEkkrIKKKKzGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXD/ABm+M3/Ctf7N 8IeEPDf/AAkv
jnxL5yeEvCUd59n+1eVs8+8up9j/AGPT7fzYjcXZR9nmxRRRz3Nxa2s9D4v/ ABu8S+G/EsHw
j+B3gWx8ZfEC6sV1F9E1HXX0zTtJ04u6C91K9jtrl7SOV4pYbdEgmmuZo5BH H5NteXFrf+DP
wZ/4Vr/aXi/xf4k/4SXxz4l8l/Fvi2Sz+z/avK3+RZ2sG9/sen2/myi3tA77 PNlllknubi6u
p/aw+Co4KjHF45XT1hTvrPzlZ80Ka6vSU/hpte9Up5uTk+WP39v+D+XXsz4M /Bn/AIVr/aXi
/wAX+JP+El8c+JfJfxb4tks/s/2ryt/kWdrBvf7Hp9v5sot7QO+zzZZZZJ7m 4urqfuKKK83F
Yqvja7rVneT9EkkrJJKyUUklGKSUUkkkkkXGKirIKKKK5xhRRRQAUUUUAFeH f8FOv+UbH7Qv
/ZDvFn/pnuq9xrzj9sT4QeJf2g/2Rvin8A/Bl9Y2useOPhxrnh/SbnVJXS2i ubywmtonmaNH
dYw8iliqswUHCk8H2uG8RRwnEWDr1pcsIVacm3skppt/JGdZOVKSXZno9Fcr 8Cfi/wCGv2g/
gh4N+PngyxvrXR/HHhXTvEGk22qRIlzFbXltHcxJMsbuiyBJFDBWZQwOGI5P VV5eIw9bCYid
CtHlnBuLT3TTs18mWmpK6CiiisRhRRRQAUUUUAFeVfEj9nn+zvGl7+0N+zjp eh+H/iVc+W2u
TzQfZrLxvbxRrGlhrLwxtI+2NFW2vtks9gwzGs1vJd2V36rRXZgsficvqudF 7q0l0lF2bjJd
Yuy0fVJrVJkyipqzOH+DP7Q3w1+OH9paN4b1T7D4o8O+TH4z8C6rPCmteGLi XfshvraOR/K3
+VI0Uys8FzGontpZ4HjlbuK4f4zfBn/hZX9m+L/CHiT/AIRrxz4a85/CXi2O z+0fZfN2efZ3
UG9Ptmn3HlRC4tC6b/Kilikgube1uoKHwg+Pt/418Sz/AAr+K/w0vvAnjqzs WvDoGoahBd22
sWkbpDNqGlXcLYvLNZ3VD5iW93Es1s11aWv2u3EndiMDh8XRlisArRj8dNtO UPNbOdN78yV4
axqacs6kqTi+WX3/ANbP8+nZej0UUV4poFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABXnHxf+L/i
Wx8SwfA74HWNjqfxA1OxW8d9RieTTvC+nO7xjVtSEbo7Rl45Ut7RHSa+mhkj jeGGC8vLOj8S
PiR40+InjS9/Z8/Z81n7Dqlj5a+O/HaW0c8XhCKWNZUt4ElVornWJoZEkht5 FeK1iljvLtHR
7Oz1Hq/hB8IPDXwa8NT6Lot9fanqGp3zaj4l8S6zKkmo69qLoiSXt3IiIjSF I4o1SNEhghhh
t4I4YIIYY/co4ahltKOIxaUptJwpO+z1jOp0UWtYxvzTVpNKnKMpZuTm7R27 /wCX9fiHwg+E
Hhr4NeGp9F0W+vtT1DU75tR8S+JdZlSTUde1F0RJL27kRERpCkcUapGiQwQw w28EcMEEMMfV
UUV5OIxFbFVpVasuaUt3/X4LZLRFpKKsgooorEYUUUUAFFFFABRRRQAUUUUA eHf8Exf+UbH7
PX/ZDvCf/pnta9xrw7/gmL/yjY/Z6/7Id4T/APTPa17jX0HFn/JU4/8A6/Vf /S5GOH/gQ9F+
QUUUV8+bBRRRQAUUUUAFFFFABXK/F/4QeGvjL4ag0XWr6+0zUNMvl1Hw14l0 aVI9R0HUUR0j
vbSR0dFkCSSxskiPDPDNNbzxzQTzQydVRW2HxFbC1o1aUuWUdn/X4rZrRiaU lZnlXw3+K/xK
8H+NLL4H/tQ3Oht4i1fzH8IeMPDelTafo/inZG001nHbz3FzJY6hBGkjtaPc TfaLeJrqCRxH
e29h6rWH8SPhv4L+Lngu9+H3xB0b7dpd95bSRpcyQSwyxSLNBcQTwssttcQz RxzQ3ETJLDLF
HLG6OisPOPDHjL4ifs6eJdO+G37QXxBvvFvhvXr6Gz8KfFHV7OztrmPUZ3CJ pOrpZQQWsUk0
rBLK7ihhhnZ0spUjuxbSap7E6FHOYOth0o1lrKmlZT7ypJKy6uVPRJ60rxfs 6Wabp6Pbv/n/
AJ/f3fsdFFFeCahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUU
AFFFFABRRVHxP4n8NeCfDWo+M/GfiGx0jR9IsZr3VtW1S7S3trK2iQySzzSy EJHGiKzM7EKq
qSSAKqEJ1JqMVdvRJbthsXqK84+Iv7Yn7I3wfsLHVfi1+1N8OPC1rql9qFlp tz4j8cWFjHd3
NhP9mvoImmmUSSW8/wC6mRctFJ8jhW4rlfFf7cPhSy/aU8V/stfDHwf/AMJ5 4w8D+BrDxF4h
8KeG/FWlRa0/228EEEFta3tzBE3lQh7m6eee38iO507y1uDeqI/YwvDueYuP NDDyUUpScpLk
ioxlGEm5ytFKM5RjJt2i2k7Gcq1KO7/rc9xorh/2YvjN/wANHfs1/D39ob/h G/7G/wCE88Da
T4i/sf7Z9o+w/bbOK58jzdiebs83bv2Lu252rnA5T4/fE/43r8b/AAZ+zf8A APX/AAr4f1jx
N4V1/wAS3Pibxf4ZudatobbSrnSLVrNbO2vrF/MmfWY5BObjbGtoyeVIZg8W dHJsXUzWeX1G
oThz8/M7qPs1KU23FSb5VGXwqTdtL6A6kVTU1qnb8dj2OiuH/Zi+M3/DR37N fw9/aG/4Rv8A
sb/hPPA2k+Iv7H+2faPsP22ziufI83Ynm7PN279i7tudq5wOU+EPxu+N/in9 rn4n/AP4p+Bf
Cuj6P4T8K+Hda8JXPh/XbnULnULbUb/X7bzrxpra3S3kKaVCfs0ayrEzSf6T OHURjyTMIvFx
mknhf4ico3X7yNKyV/etOST5bpLXYPaQfLb7W33XPY6KKK8k0CvHPE/xwv8A 45eJdR+CP7KP
juxlutLvprD4gfETS3gvrbwbJG5jmsIQweG41wlWC2sivHZLi5vEZTa2Woni fxP4l/ab8S6j
8KPhR4hvtI8D6RfTWHj3x7pF29vc6hcxOY59D0ieMh45EdWivdRjIa1ZXtbV hfCefSvVfDHh
jw14J8Nad4M8GeHrHSNH0ixhstJ0nS7RLe2sraJBHFBDFGAkcaIqqqKAqqoA AAr3oUsPk0FU
xEeeu9YwdnGHaVSLT5n1jTdls6ilG9OWTbqaLb+tv8/u7lH4b/DfwX8I/Bdl 8Pvh9o32HS7H
zGjje5knlmllkaae4nnmZpbm4mmkkmmuJWeWaWWSWR3d2Y7lFFeLWq1cRVlV qycpSbbbd229
W23q23q2zRJJWQUUUVmMKKKKACiiigAooooAKKK+ZP2vf2tfjf8AB/xL8TLr 4WReFYtH+CPw
ctPiP4tsPEGi3N5c+Krad9bP9mWc8N3AmlSKmgzL9qkivlLX0beQBbss/rZN k2MzzF/V8PZP
TVuyXNKMIrRN+9OcYrSyck5WipSWdSpGnG7/AK/pH03RRXjn7JHxu+N/xe1j 4q+Gvj54F8K+
HdY8A/EeHw/bad4Q1251O2+zSeHtG1RXa7uba1eeQvqUmSLeFVUKm1yhlk58 Nl+IxeEr4inb
lopOV2k7SkoK0b3esldpWV1dq6vTmoySfUo/8E1/+JX+wz8OPhvcc33w60Nv AGtypzFPqXh2
eXQr2aAnlrd7rTp3hZgjtE0bOkbFkX3GvDv+Cev/ACQXX/8AsuPxO/8AU716 vHPE37fH7TWg
/DtPGOt6V4V02PxZ8f8AxN8OPBF34f8Ah9r3iu5sLbRrzxKX1O80rTpUur6S aLRI7X7LbMiw
MZL953jc2Nv9fmXDuY59xTmP1W3u4iad7396VSWkUnKVownJqKcmo2ipSaT5 4VoUqEObsv0/
zPtSivg/UvjH+01+0b43+Amj+LZLHTdHsP2m5dK1ibxL8Fte8Pw+OLa08IXu vW19DpOrXkc9
lHbXMU8Efnm6X+0NNtdQjdRbC1f0f9iL9nn4a+HfiVY/Gz9nPS/sPga28DT6 Ff8AjS4ghGpf
GXUpZrGUeKdRlgji+3+V9kuRBqM4d759Y1C4hWO2eG41CMw4MhlOBdXGYnlq cnOoqEuXWVSM
IylJxcZz9neMFCU4pv2kYKFVwIYn2krRWnr6flff7r3V/qmiiivhTqCiiigA ooooAKKKKACq
Pifwx4a8beGtR8GeM/D1jq+j6vYzWWraTqlolxbXttKhjlgmikBSSN0ZlZGB VlYggg1eoqoT
nTmpRdmtU1umG54d5OrfsS/6PoPhbXNc+Dkny2WieGNAutV1LwJKeEt7Sys4 5bm80eRsJHbw
RyS6a7KiI2nsF0n2Pwx4n8NeNvDWneM/BniGx1fR9XsYb3SdW0u7S4tr22lQ SRTwyxkpJG6M
rK6kqysCCQavV454n8G/ET9nTxLqPxJ/Z9+H194t8N69fTXniv4XaReWdtcx 6jO5d9W0h72e
C1ikmlYve2ks0MM7O97E8d2LmPVPe9pQz3+K1DE/zykowqf427KNR9ajkozt edpuU55WdLbb
8vTy8v00PY6Kw/hv8SPBfxc8F2XxB+H2s/btLvvMWOR7aSCWGWKRoZ7eeCZV ltriGaOSGa3l
VJYZYpIpER0ZRuV4dalVw9WVKrFxlFtNNWaa0aaeqaejTNE01dBRXnH7Rf7S 3hr9m+HwjHrX
gLxV4l1Dxz4qbw54a0fwhpaXdzcaj/Zt9fxxsHkjSKN0sJYzPIywws6yTvDA s08XK/8ADdXh
T/hK/L/4Ur45/wCEG/4Tn/hD/wDha2NK/sX+2v7V/sX7L9n+3/2p/wAhf/iX +Z9h8vzP3u/7
N/pNethuHs5xeHhXpUrwnflbcVzNNx5Y3a5ptpqMI3nNxlyxfK7Q61OLs3/X 9dT3Givjn4af
G39of9oX9njxL8e/iH8R/ir8IdO0j4q+KdMuNG8E/DvSPEWu/Z7DV/7Hsrez htLfWd9un2ec
3ga3nne+8+WC4g0+GNJvo79mLx740+Kv7Nfw9+KHxIh0OPxF4k8DaTqmvx+G L+O601b24s4p
pxaTxTTRzW4kdvLkSWVWTaRI4IY9WccMYzJaU51qkJOFR0pKLk+Wau2ublUJ WS1dOU+W8ea3
MrzTrRqNWT1V/l/Xc7iivkf4m/Hv48aX8WfHfxG0X4tX1lo/w7+P/gb4c2vg GHStPbSdXsNb
HhYXV7eSSWzX/wBsj/4SO5MRt7qCAGztN8MgE4uPqrxPb+Jbvw1qNr4M1axs NYlsZk0m/wBU
057y2trkoRFJNBHNC88avtZo1liZ1BUSITuHPmOQ4jLKOHq1akXGqk7rm928 KdS0rxWqhVg3
y8y1sm2mioVVNtJbf8FfoXqK8c/YQ+IPxZ+JX7P0+u/HHxhY694msPiP410S /wBV0vRhp1tN
HpvinVdPgENsJJDDGsFrEiq8ksm1R5ksr7pG9jrhzPAVMqzKvgqklKVKcoNx vytxk4tq6Ts7
XV0nbdJ6FQmqkFJddQooorhKCiiigAooooAKKKKACiiigAooooAKKKKACvKv 26/hv40+Mn7E
Xxk+EHw30b+0vEXiv4VeIdH0DTvtMcP2q9udNuIIIvMlZY03SOq7nZVGckgA mvVaK7MuxtXL
Mwo4ykk5UpRmk9rxaavZp2utbNepM4qcXF9T45+P/wCzz8evhd+0o/xI/Zn0 v4q6V4PvvhV4
c8JadoHwBg8CQf2d/Y95rMqx3UHiqNYobcQ6pAlstiTjyrlZlQLblu5/Y0/Z g8afs5/Er+zL
7w79m8O6R+zl8N/BWlXf9vR6hvvdFm8RC6g84Q20k3lx3tmfPa2t1l87KxoQ 8cf0bRX0mL41
zPG5PLL6lOnacYQnNRaqTVNxcHOXNaUoqCim1onLq7mMcNCNTnTf6K/Y8q/Y U+G/jT4N/sRf
Bv4QfEjRv7N8ReFPhV4e0fX9O+0xzfZb22023gni8yJmjfbIjLuRmU4yCQQa o/H74YfG9vjf
4M/aQ+AegeFfEGseGfCuv+Grnwz4v8TXOi201tqtzpF014t5bWN8/mQvo0cY gNvtkW7Z/NjM
ISX2OivJWeYn+2quZShFyqOo5R15Wqqkpx0kpJNSaVpcy6O+pp7KPs1Dtb8N jyr9nz4UfEr9
mr4A+BP2c/D1tofiOx8A+BvC/h228QXuqzafLqX2VVs9Qna2W3nFvstYo7iB BNJ58sjQO1uq
C4e94Y+EHiXRf2ufHHx8ur6xbR/Evw48K+H7C2jlc3Mdzpl/4huZ3kUoEEbJ q1sEIYsWSXcq
gKX9HorOtnOLrzxFSVubEX9o7ayvOFRu17K84KWiS1aWlkhU4pJLpt+QV4d/ wl/xK/a9/wBB
+Fl3/wAI78H77if4i6drk0GteK7dfvx6OkcY+yafcbgqayJxPJHFM1lCiXFl q6n/ACfF/wBk
O/8AVl//AIP/APp3/wCwZ/yF/ca6rU8h0nFSxXZ7UfVda3eLvGltJOq2qK1q 7fD+f/A/P03o
+GPDHhrwT4a07wZ4M8PWOkaPpFjDZaTpOl2iW9tZW0SCOKCGKMBI40RVVUUB VVQAABV6iivB
nOdSblJ3b1be7ZrsFFFFSAUUUUAFFFFABRRRQAUUUUAFfMn7Xv7JXxv+MHiX 4mWvwsl8Ky6P
8bvg5afDjxbf+INaubO58K20D62P7Ts4IbSdNVkZNemb7LJLYqGsY188i4Zo PpuivWybOcZk
eL+sYezemjV0+WUZxejT92cIyWtm4pSvFyi86lONSNn/AF/SMP8AtD4lf2/9 n/4RPQ/7L/tz
yvtn/CQzfaP7N+wb/tPk/ZNv2j7d+4+z+Zs8j/SPP3/6LXKfBD4QeJfhr8TP jF4z12+sZbX4
hfEe18QaLHaSu0kNtH4a0PSmScMihZPP0ydgFLr5bxncGLKvo9Fc9PH1KNKp TpRUVUgoS3d0
pxnfVuzcoRvaytskU4ptN9Dw7/gnr/yQXX/+y4/E7/1O9erqtc/ZN+A+v/Ds /DCfwpfWemr4
q1HxLZ3OjeJdQ0/UbDVr+8u7u8vLTULWeO7s5JZb69VjBKgMN3NBjyZGiPK/ sLf8U1oHxO+D
N98+qeCvjj4r/tWeHm3l/tq/bxTa+UxwzbLHX7OOTcq7Z4p1XeipLJ7jXucR Y7G4TibF1cNV
lBTqurFxk1dScpU5qzW8J3i90pPuzKjGMqMVJbK3+a/A848G/sm/AfwJD4fG ieFL6e68M+Kp
vEum6vrPiXUNR1GbVpdNuNLa8u727nkuL+QWFzJaqbmSUJCsKIFWCER0f2ef 2Mvgd+yz9lt/
gzN45tbGw0NNH03RNc+K/iLWdNsbJPLEcVvZajfz21vsWJERo41ZEBRSFZlP qtFeXUz7PatK
pTniqjjUspJzk1JJya5lezs5yavezlJ9Xe1SpJpqK08goooryTQKKKKACiii gAooooAKKKKA
CiiigDyr4kfBn4laF40vfjR+y94k0PR/EWqeW3i/w34ks5pNH8W+TGqQvI0D iTTtQ8uKO1XU
0S4xb7UntL4Wtklt1fwg+L/hr4y+Gp9a0WxvtM1DTL5tO8S+GtZiSPUdB1FE R5LK7jR3RZAk
kUivG7wzwzQ3EEk0E8M0nVV5x8X/ANnew8e+JYPi14A8WX3hD4h6ZYrb6T4o 0+4na2uY43d4
rXVbCOaKHV7NTLcKIZ/3kC3ly9pNZ3Ev2lfco4zDZhSjh8fLlcUlCpa7SWij Ut70oJWSfvTh
FJQjKKUDJxcHeP3f5ef5/iX/AIs/Bn/haHj34Y+N/wDhJPsP/CuPHNx4i+y/ Y/N/tHzdB1bS
fI3b18nH9qedvw+fI2bRv3r8/wDh7/glP4E8MftCSfFnTdH+Dkuny/Ee68aN rWo/AaxvPHAv
7jVJNWkjHiCe5eJYxdyNFG4sBPFZhIo5UnRL1foD4M/Gb/hZX9peEPF/hv8A 4Rrxz4a8lPFv
hKS8+0fZfN3+ReWs+xPtmn3HlSm3uwib/Kliljgube6tYO4ruo8Q8T8O82Dp 1eRcnI1aEk4N
ymrOzUk3UlKM03eMrxk4tEujQre81fr89v02PDtA/Zr+P3wn8BL4a/Z//aO0 PSr6Txz4t12/
Hiv4etqum3cWua9d6wIzbwX9pcpcWrXIgjmW7ETo07SW7M8JtvR/gT8IPDX7 PnwQ8G/APwZf
X11o/gfwrp3h/SbnVJUe5ltrO2jtonmaNERpCkaliqqpYnCgcDqqK8vHZ3mW Y0pU68k1KbqS
tCEXKbcnzScYpytzy5btqKbUUloXGlCDuvQ8A8b/ALFXiXxX8Wdc1mw+L1ja eBfF/wAR/D3j
zxd4cm8LPNq0uuaKNJ+xiz1EXaQ21mx0LTDLDJZ3ErD7WFnj86I2/sejaf8A EqDVoJvEPizQ
7qxX+0vtNtZeHpoJZN90jaftka7kCeTaiSKfKN9plZZk+yqpgbcooxeeZlj6 FOjXkpRppKPu
QVkoqG6im3yxiuZ3laMdfdjYjThFtrqcP+z18Gf+FD+AtQ8Ef8JJ/av27xz4 n8RfavsfkbP7
Y16/1byNu98+T9t8nfkb/K37U3bF7iiiuHF4qvjsVUxNd3nOTlJ6K7k7t2Vk rt9FYuMVGKit
kFFFFc4wooooAKKKKACiiigAor5Y/wCCn9rq3iPUf2ffhrb+PvGGgaX4r+OE 9h4hPgrxtqfh
+6vrWLwb4nvUt3u9MuILjyvtNpbSlBIFZoU3AgYrh/8AhiX4Yf8ARY/2gP8A xKfx9/8ALqu7
DZfWxdNzg1a9tb/5Hn4vMqGDqKE022r6W/zPt+iviD/hiX4Yf9Fj/aA/8Sn8 ff8Ay6o/4Yl+
GH/RY/2gP/Ep/H3/AMuq6f7GxXeP4/5HL/bmE/ll9y/zPt+iviD/AIYl+GH/ AEWP9oD/AMSn
8ff/AC6o/wCGJfhh/wBFj/aA/wDEp/H3/wAuqP7GxXeP4/5B/bmE/ll9y/zP t+iviD/hiX4Y
f9Fj/aA/8Sn8ff8Ay6rzHxt4O/Z58LeKrvwT4b8bftS+L9S0xwmsQeE/2lfH dwunuQCElkk1
6NA+DkorMyj7wGRnnxOAeEhz1qkYrzb/AMhSz7BRWql9y/zP0tor89fhN8DP 2dPjRo1xq3gr
46ftCGWwuPs+q6beftQ+P4brT59obypo21rKnBBBGVYHKsw5rE+Lvg/9k/4J +JIPBni34y/t
U6lrE1it7LpXgn4y/FjxLc2ds7ukU91FpF/ctaRyvFOsTzBFma2nEZcwy7Lp 5bUq0lUhOLi9
nd2/IqGeYSp8MZP0S/zP0lor4E+HH7Nv7Pvxb8F2XxA+H/x8/aAvtLvvMWOR /wBp/wCIUEsM
sUjRTW88MusLLbXEM0ckM1vKqSwyxSRSIjoygsP2bf2fdU+JOrfCKx+Pn7QD +ItD0PT9Y1TT
/wDhp/4hDyLK+mvYbWXzDrGxt8mnXi7VYsvk5YKHQtp/Y+Jf2o/e/wDIf9t4 XX3ZaeS/zPu3
xP4n8NeCfDWo+M/GfiGx0jR9IsZr3VtW1S7S3trK2iQySzzSyEJHGiKzM7EK qqSSAK8c/wCF
b6t+2V/xU/xx0bXNH+Gp/wCRb+G9zc3Wm3HiGI8Ne+IIEaOR7eaMtGmh3AMX kSu2owyXEqWm
mfJfxN+Cf7B9r8WPCn7L3xU/ad+K11408WX0N/4W8Caj+1V45ur65ksxPqMN +LX+2WaKOF9M
lljunVY0ntkVXEvlqfRv+GJfhh/0WP8AaA/8Sn8ff/LqvUwNDE5fSc8M0q97 Kd37isvhsrqb
1vLdK3Lq2zOecYVtc0ZW9Fr+Ox9v0V8Qf8MS/DD/AKLH+0B/4lP4+/8Al1R/ wxL8MP8Aosf7
QH/iU/j7/wCXVeZ/Y2K7x/H/ACK/tzCfyy+5f5n2/RXxB/wxL8MP+ix/tAf+ JT+Pv/l1R/wx
L8MP+ix/tAf+JT+Pv/l1R/Y2K7x/H/IP7cwn8svuX+Z9v0V8Qf8ADEvww/6L H+0B/wCJT+Pv
/l1Xcf8ABMC11bw5qP7QXw1uPH3jDX9L8KfHCCw8PHxr421PxBdWNrL4N8MX r26Xep3E9x5X
2m7uZQhkKq0z7QAcVzYnL62Epqc2rXtpf/I6sJmVDGVHCCaaV9bf5n1PRRRX CegFFFfmZ+wv
+zbonxj/AGJfg78XfiP8fP2gNR8ReKvhX4e1jXtQ/wCGn/HMP2q9udNt5p5f Li1hUTdI7NtR
VUZwAAAK6sLhKmLk1BrTucmLxtLBxTmm79v+HR+mdFfEH/DEvww/6LH+0B/4 lP4+/wDl1R/w
xL8MP+ix/tAf+JT+Pv8A5dV2/wBjYrvH8f8AI4P7cwn8svuX+Z9v0V8Qf8MS /DD/AKLH+0B/
4lP4+/8Al1R/wxL8MP8Aosf7QH/iU/j7/wCXVH9jYrvH8f8AIP7cwn8svuX+ Z9v0V8Qf8MS/
DD/osf7QH/iU/j7/AOXVct8VfgP+zx8HNHt9U8Y/HH9oUzX1x9n0rTLH9qDx /Nd6hPgnyoYl
1rLHAyScKo5ZlHNZ1crq0KbqVJxUVu23/kDz7BpXal+H+Z+hFFfmj4K8J/s6 +KPF1n4E8S+O
f2pPCGqam5TRrfxZ+0t47txqDgMSkTx69IhfCkhGZWYA7QcNjs/iR+zb+z78 JPBd78QPiB8f
P2gLHS7Hy1kkT9p/4hTyzSyyLFDbwQxaw0tzcTTSRww28SvLNLLHFGju6qcs PgXi6bnRqRkl
1Tf+QoZ9g5/DGX3L/M+iv2Tf+S9ftO/9lx0//wBQTwnXuNfmZ8C/hR+xV8Tf GmtaF8NfiJ+0
34f8Rat/xOtVs/Ffxa+Kvha91vyo7aze9RNVvrWTUPJjSxt5JoxJ5KtZxyFB JAG7j4hfs2/s
+/CvQbfxP49+Pn7QFhY3WuaZo8E//DT/AMQpd17qN/Bp9nFtj1hiPMurmCPc RtXfuYqoZh7O
aYarmWIjWg0kqdKG/wDz7pQpt7dXG/oxwzjD0/dcZXu+i6u/c++6K+BPiR+z b+z78JPBd78Q
PiB8fP2gLHS7Hy1kkT9p/wCIU8s0ssixQ28EMWsNLc3E00kcMNvEryzSyxxR o7uqmj8Ivgb+
zb8cvDc/ij4efHX9o147O+ay1LT9Z/aM+JOl6jp1yqJJ5F3Y32qw3NpI0UsM ypNGjPDPDKoa
OWN283+yMRe3NG/q/wDIr+28Ny35ZW9F/mfoTRXxB/wxL8MP+ix/tAf+JT+P v/l1R/wxL8MP
+ix/tAf+JT+Pv/l1Vf2Niu8fx/yJ/tzCfyy+5f5n2/RXxB/wxL8MP+ix/tAf +JT+Pv8A5dUf
8MS/DD/osf7QH/iU/j7/AOXVH9jYrvH8f8g/tzCfyy+5f5n2/RXxB/wxL8MP +ix/tAf+JT+P
v/l1WHZ/CO3+AP7YX7OV58PfjH8YJovEvxU1TR9f03xT8dfFWvWF/ZDwX4mv BFLaanqVxA22
5s7aVWKblaFSCOc5VsrxFGk5yasvX/I1o5vhq9VU4p3fp/mffdFFFeaeqFFF fKX7cfi/4/aj
+1t8J/gL8I/2nPFXw00fXfhz401/Xbnwho2hXVzfXOnX/hm3tUZtX069VI1T VLskRqjMzLli
FArSlTlVqKEd2Z1asKNNzlsj6tor4w/4VF+1p/0lS+OH/hL+AP8A5l6P+FRf taf9JUvjh/4S
/gD/AOZeu/8AsnGdl95539s4Lu/uPs+ivjD/AIVF+1p/0lS+OH/hL+AP/mXo /wCFRftaf9JU
vjh/4S/gD/5l6P7JxnZfeH9s4Lu/uPpf4zfs8/DX44f2brPiTS/sPijw750n gzx1pUEKa14Y
uJdm+axuZI38rf5UaywsrwXMamC5ingeSJsL4b/tAatYeNLL4A/tEaT/AGL4 8m8yPS9UsdHu
ovD/AIsWONpRPp11JviiuHhinlfSZZ2vbcWt0wFzawpfz+C/8Ki/a0/6SpfH D/wl/AH/AMy9
YXxI/ZZ/aA+Lngu9+H3xB/4Kc/HC+0u+8tpI08P+BIJYZYpFmguIJ4fDKy21 xDNHHNDcRMks
MsUcsbo6Kw9jC0a86CwmOTlSXwtNc1O7u3G+jjdtyp3ipPaUG+Yzlm2CT5ot 39N/67n3ZRX5
2eNfil40+H/iObwn4l/4LJ/G0X9s+y7gsPAvgm8Fs/XZK1v4TdYmA5KuQQCC RyK7fw74E/aU
8XaJbeJfCv8AwVt+Muo6dexCS0vrHw98PpYpkP8AErr4YII+leBTwU61Rwpz i5LdKSbXquhS
zzL5NpS2Ptyivzq+LvxkX9n3xJB4M+PX/BfbxV4I1i5sVvbbSvF998MdNuZb ZndFnWK48Ooz
Rl45FDgbS0bDOVOPRv8AhUX7Wn/SVL44f+Ev4A/+ZetllWKbsrfeW83waSbv 9x9n0V8RaT4I
/aP16/1PStC/4K5/GK9utEvlstZtrTQvh7JJYXLQRXCwTKvhgmKQwXEEoRsM Y5o3xtdScPVt
X+I+g/FjTPgLrv8AwW0+I1l451uxa90bwXd2/wAN49Wv7ZRKWnhs28NCaWMC 3nJdVKgQyc/I
2D+ysWu33gs4wb7/AHH3zRXxh/wqL9rT/pKl8cP/AAl/AH/zL0f8Ki/a0/6S pfHD/wAJfwB/
8y9P+ycZ2X3i/tnBd39x9n0V8Yf8Ki/a0/6SpfHD/wAJfwB/8y9H/Cov2tP+ kqXxw/8ACX8A
f/MvR/ZOM7L7w/tnBd39x9n0V8Yf8Ki/a0/6SpfHD/wl/AH/AMy9H/Cov2tP +kqXxw/8JfwB
/wDMvR/ZOM7L7w/tnBd39x9n0V4L/wAE1viN8Ufih+ypHrvxk+I994u1/Tfi N440CXxHqdhZ
W1zfW2l+LNX0y0eWOxggtxILa0gVjHFGrMpbbkmivNknGTTPUjJSimupzX/B Rv8A5Kf+y7/2
cBe/+oD4vrfrkv8AgqDb+JLvxV+zba+DNWsbDWJfjlqSaVfanp73dtbXJ+H3 jERSSwJNC00a
vtLRrLEzqCokQncPPf8AhAf+Ckf/AEdf8D//ABHzWP8A5rK+iyeTWGdlfV9u y8z5jO4qWLV3
b3V37vsj2+ivEP8AhAf+Ckf/AEdf8D//ABHzWP8A5rKP+EB/4KR/9HX/AAP/ APEfNY/+ayvV
55fyv8P8zx+SP8y/H/I9vorxD/hAf+Ckf/R1/wAD/wDxHzWP/mso/wCEB/4K R/8AR1/wP/8A
EfNY/wDmso55fyv8P8w5I/zL8f8AI9vr4y+CnxD+Pdl+ybqfwc+Dfxg8NeEP i7oHxRupfGkP
iDVItOuL+0IYed50zqJf3p3n5zvXLch13evf8ID/AMFI/wDo6/4H/wDiPmsf /NZXn3xS/Yb/
AGp/jRrSeJPiN8avgReaikYjN/bfAfX7SaVB91ZHt/GCNIF/hDk7cnGMmvCz zLcRmUYOlo43
3dtHbqrtPTt3IlTknzU5pOzW8lo7bNJ2at2fVdSf9k+9+KXif9tP4ieI/Evx X0bxtZWmgw2m
r+KPDmk/Y7O/vmkikiChfkcxqLoZH9/d0kBZ37VfxB+Bfwq/aSuPFPiL9sb/ AIZ/8YXPgfSh
D4k8XXOiReG/HFvb3mpva6bIuqDzbr7BNLcSXUWnzWM4h1q3DXIMlu8G/wCA v2f/ANu34X+G
ofCHw+/aI+Amk6bASyWtn+zvrChnP3nY/wDCWZd26l2JZjySTWz/AMID/wAF I/8Ao6/4H/8A
iPmsf/NZXRlmBq4DAqjLV3bb8321v8+pWHpqjfmne7b6vd36p3+d++5478Ov 2pbDwZ4x+Evx
g+JF5Y+D/A2ueFfiXZzv4Zsp4NE8aeIT4m0c6ZqOnWURkN5eazBDqmqWFtEb q6nivrjyJLvd
JNJ4f+z78Q/gTr/iTwB4s/bf/a58VeDrXXP2LvhHf3OuXnxP1Dwvba5qzv4k dpb3XLea3me8
xJO8do94ouVku5mguGtBLbfaX/CA/wDBSP8A6Ov+B/8A4j5rH/zWUf8ACA/8 FI/+jr/gf/4j
5rH/AM1ldjp1G02tvTsl/Mdaq00mk1r5vvf+U8503xD8WPF3gL9hLxX8ere+ i8c6n4qs7vxp
FqemCyuU1aT4beJXvFltwiC3kE7SBogiBGyu1cYH1rXiH/CA/wDBSP8A6Ov+ B/8A4j5rH/zW
Uf8ACA/8FI/+jr/gf/4j5rH/AM1lbQ5oJ6N/d2S7mE1CbXvJff3b7eZ7fRXi H/CA/wDBSP8A
6Ov+B/8A4j5rH/zWUf8ACA/8FI/+jr/gf/4j5rH/AM1lXzy/lf4f5kckf5l+ P+R7fRXiH/CA
/wDBSP8A6Ov+B/8A4j5rH/zWUf8ACA/8FI/+jr/gf/4j5rH/AM1lHPL+V/h/ mHJH+Zfj/ke3
1gf8E5P+Sn/tRf8AZwFl/wCoD4Qry/8A4QH/AIKR/wDR1/wP/wDEfNY/+ayv Qv8Agl9b+JLT
xV+0la+M9Wsb/WIvjlpqarfaZp72ltc3I+H3g4SyRQPNM0MbPuKxtLKyKQpk cjcfKziTeFV1
bVduz8z2Mkili3Z3919+68j6tooor5w+oCvhD/gmV/yjc/Z8/wCyH+E//TPa 1931+Xn7CPhH
9tvVP2D/AIEX3wi/aD+Feh+HX+B/g/8As/S/Enwd1LVb2DGh2Qk8y6h8Q2iS 5kDsu2BNqsqn
cVLt7OTNqrKyvoeHniTpQu7as+w6K8Q/4QH/AIKR/wDR1/wP/wDEfNY/+ayj /hAf+Ckf/R1/
wP8A/EfNY/8Amsr3+eX8r/D/ADPm+SP8y/H/ACPb6K8Q/wCEB/4KR/8AR1/w P/8AEfNY/wDm
so/4QH/gpH/0df8AA/8A8R81j/5rKOeX8r/D/MOSP8y/H/I9vrwD4k+O7X4S /wDBQ/4deOPi
Xq1np3hK/wDB99p2lavqkO+2sNX3SsHJORGW3W2TgZCZziMldD/hAf8AgpH/ ANHX/A//AMR8
1j/5rKxfH37P37dnxS8MzeDviF+0R8BNW02chntbv9njWGCsPuup/wCEsyjr 1V1IZTyCDXnZ
phamPwjpRVndNXta6d9ddhOFnGUZq6aa3to766bHiPx31X9tbWPAeheCfiv+ 1D4M8U+IdR8d
Rx+GfDegyQ6leJIdpjv1uoXYwRiRVKoSu0LvIUKSv1H+2j/wraP9nrUb34tf 25b6HZ65od3L
rfh7yRceHLiHV7OW2112uMwJb6dcJDqM8k6yQJBZStNFLErxP5J8Lf2HP2p/ gvrL+I/h18av
gPZ6i8ZjW/uPgNr93PGh+8sclx4wdow38QQjdgZzgV6B/wAID/wUj/6Ov+B/ /iPmsf8AzWVw
ZJlVfLadT2mrnbrdK1+ra79kRQpOFT2k6l3pu5Pbza/Reh85+Pfjvr3xF+G3 xa8Dfsx/tL6H
+0Prmnfs6eNrjwX8Uvh3BYXHizwlqRhtPI0u5vNCIge41G4dZbRLa2sHxoGC l5LG08WH+2B+
1B4L+PGs/FbUfhB8etc1bwVon/ChptL1/wAB2smsW8F7J8Rr/wC1X2jRC3ub fUrgLDbxFreG
6WSeyFs6ySW7wJ9Uf8ID/wAFI/8Ao6/4H/8AiPmsf/NZR/wgP/BSP/o6/wCB /wD4j5rH/wA1
leu6dRq2v4dmv5vM7o1aUWnpp690/wCXy/4c8B079pj9nT4N6P8AFbxv4A+J 1j8Vvgh4dsfh
/N4f1rxX8U5vE2iWXjW98QX1q7T6/qU981nHaOvhu8nVXk+wRbLuK382b9/9 F/sXX/wS8S+B
fEPxD+EP7Q3hX4p6l4n8VPqHxA8a+DdVtrixu9bFlZ25ijitppo7OOGzgsYI rcyPKsEULTS3
Ezy3M1L/AIQH/gpH/wBHX/A//wAR81j/AOayj/hAf+Ckf/R1/wAD/wDxHzWP /msrSEZxa0/L
/Micqc4tKX5+X935/wDDHt9FeIf8ID/wUj/6Ov8Agf8A+I+ax/8ANZR/wgP/ AAUj/wCjr/gf
/wCI+ax/81la88v5X+H+ZhyR/mX4/wCR7fRXiH/CA/8ABSP/AKOv+B//AIj5 rH/zWUf8ID/w
Uj/6Ov8Agf8A+I+ax/8ANZRzy/lf4f5hyR/mX4/5Ht9eYfF3/k7T9lb/ALLh qn/qAeLq5/8A
4QH/AIKR/wDR1/wP/wDEfNY/+ayse30D9pLQ/wBrT9mj/hoT4seB/FHm/HC+ /sj/AIQz4e3m
g/ZseAPGXm+d9p1bUPP3Zj27fK2bHzv3jZy46UnhJ+69vL/M7MBCKxkHzJ6+ f+R+g9FFFfIn
2gV8oftZf8pI/gn/ANkP+JH/AKePBFfV9fGn7fN/8SdL/bw+EF98IvCeh654 iT4H/ET+z9L8
SeIZtKsp8654FEnmXUNpdvFiMuy7YH3MqqdoYuvXgXbFw9TjzBXwU15HpdFe If8ACff8FI/+
jUPgf/4kHrH/AMydH/Cff8FI/wDo1D4H/wDiQesf/MnX1vtI+f3P/I+L9lLy +9f5nt9FeIf8
J9/wUj/6NQ+B/wD4kHrH/wAydH/Cff8ABSP/AKNQ+B//AIkHrH/zJ0e0j5/c /wDIPZS8vvX+
Z7fXO/F+/wDFOlfCXxRqngaN31u28O30ujpFHuZrpYHMQC4OTvC8YOfQ15l/ wn3/AAUj/wCj
UPgf/wCJB6x/8ydH/Cff8FI/+jUPgf8A+JB6x/8AMnU1JKcHFXV12YOjNq11 96/zOI+DvjL4
62f7LPwZvf2L/gJ4T8Vx+IJbtfiLPqUSXS296064+2yMGkjidC8jSfKSPmzl huuf8E8dZ8a3
fiT4raHrui6PYabp/ixPJtfDl0Z9Oiv3803Yt2P8BAt3x38wP1cs3mnjL9jD 9q3xR4nvvE2i
fsx/DLwyNUlM2pab4b/aU1OG1uZWOWcxyeDpNm7uqFV6nAJJPq/w0079ur4P +D7bwJ8Ov2MP
gXp2mWu4pCn7Q2tOzuxy0ju/hQtI7HksxJPrXyGUZLi8HmEa1R2jFNaXd9Lb WVu7v1MFRxM5
Q5nZRSVuaNnolorJq9rvV6j9P0H4vaB8cPi14y/ZA8e+B/EfneOLOX4jfD7x 1peoafKNf/4R
7R4VS21y3MqWluNMXSrnZ/Zt6XlM0Znj83/RfD9Z/bM0r4QfsdfE7xl+zv4s /wCED+Hngv8A
Yg8FeKvgpp/iRbUy6Fe6hb+JIdOjkkuGm+0XD/YdIt1hllnV5Y1Vd7SuZPRv i7+z38bf2gvE
kHjP49f8ErP2SvG+sW1itlbar4v+JlzqVzFbK7usCy3Hg12WMPJIwQHaGkY4 yxzufETwR+1t
8X7+x1X4s/8ABO39mbxRdaZY6hZabc+IvjFf3slpbX0H2e+giabwgxjjuIP3 UyLhZY/kcMvF
fUy5m3y6b9H1+Wnp1fY9GLirc1nt1j0t569u6T6njvxB8d/FL4b+MP24Pjd8 K/2nf7FvvhDr
kfjFPhzpek6ZP/a8sPw/0K4iOsNdRT3H9n3DWBgjWzNjKPJvsXMjGP7L7F+2 vb+Gxo+mal4K
1bwqdHg+PvgJPirouj6eg1i+1uTxB4aTSpJL2ObbayQIdNmmjuLaeW5slhhj ktA0dwtHxT8I
v2kvHHjSw+I/jX/gmb+yxrHiLStcGtaZr2qfFe8uL2z1IR2sQvYp5PBxeO4E djZIJVIfbZ26
5xEgW9q3gj9rbXvixpnx613/AIJ2/szXvjnRLFrLRvGl38Yr+TVrC2YShoIb xvCBmijIuJwU
VgpE0nHztks7SWuvlLz8vPbqF1eL00849l5+W+6v5H0zRXiH/Cff8FI/+jUP gf8A+JB6x/8A
MnR/wn3/AAUj/wCjUPgf/wCJB6x/8yddHtI+f3P/ACOX2UvL71/me30V4h/w n3/BSP8A6NQ+
B/8A4kHrH/zJ0f8ACff8FI/+jUPgf/4kHrH/AMydHtI+f3P/ACD2UvL71/me 30V4h/wn3/BS
P/o1D4H/APiQesf/ADJ0f8J9/wAFI/8Ao1D4H/8AiQesf/MnR7SPn9z/AMg9 lLy+9f5nsH/B
Kf8A5NL1D/suHxS/9T/xBRR/wSn/AOTS9Q/7Lh8Uv/U/8QUV8XV/iy9Wfd0f 4MfRGD/wVB1a
/wBB8Vfs267pXhi+1u6svjlqU9to2mSQJc38ifD7xiy28TXEsUKyOQEUyyRx hmG50XLDz3/h
q/48/wDSMr44f+D/AMC//NLXqH/BRv8A5Kf+y7/2cBe/+oD4vrfr38ni3hnZ 21fbsvI+czuS
ji1dX91d+77M8Q/4av8Ajz/0jK+OH/g/8C//ADS0f8NX/Hn/AKRlfHD/AMH/ AIF/+aWvb6K9
Xkl/M/w/yPH54/yr8f8AM8Q/4av+PP8A0jK+OH/g/wDAv/zS0f8ADV/x5/6R lfHD/wAH/gX/
AOaWvb6KOSX8z/D/ACDnj/Kvx/zPEP8Ahq/48/8ASMr44f8Ag/8AAv8A80tH /DV/x5/6RlfH
D/wf+Bf/AJpa9voo5JfzP8P8g54/yr8f8zxD/hq/48/9Iyvjh/4P/Av/AM0t H/DV/wAef+kZ
Xxw/8H/gX/5pa9voo5JfzP8AD/IOeP8AKvx/zPEP+Gr/AI8/9Iyvjh/4P/Av /wA0tH/DV/x5
/wCkZXxw/wDB/wCBf/mlr2+ijkl/M/w/yDnj/Kvx/wAzxD/hq/48/wDSMr44 f+D/AMC//NLR
/wANX/Hn/pGV8cP/AAf+Bf8A5pa9voo5JfzP8P8AIOeP8q/H/M8Q/wCGr/jz /wBIyvjh/wCD
/wAC/wDzS0f8NX/Hn/pGV8cP/B/4F/8Amlr2+ijkl/M/w/yDnj/Kvx/zPEP+ Gr/jz/0jK+OH
/g/8C/8AzS0f8NX/AB5/6RlfHD/wf+Bf/mlr2+ijkl/M/wAP8g54/wAq/H/M 8Q/4av8Ajz/0
jK+OH/g/8C//ADS16F/wS+1a/wBe8VftJa7qvhi+0S6vfjlps9zo2pyQPc2E j/D7wczW8rW8
ssLSISUYxSSRllO13XDHrawP+Ccn/JT/ANqL/s4Cy/8AUB8IV5WcRawqu76r t2fkexkkk8W7
K3uvv3XmfT9FFFfOH1AV+Xn7CP7Qfxb8D/sH/Ajwt4Y/YX+KnjKxtfgf4P8A I8SeG9X8JxWV
5u0OydvLXUNctrgbGYxt5kKfMjFdy7Xb9Q6+EP8AgmV/yjc/Z8/7If4T/wDT Pa17OTJurKzt
oeHnjSpQur6sP+Gr/jz/ANIyvjh/4P8AwL/80tH/AA1f8ef+kZXxw/8AB/4F /wDmlr2+ivf5
JfzP8P8AI+b54/yr8f8AM8Q/4av+PP8A0jK+OH/g/wDAv/zS0f8ADV/x5/6R lfHD/wAH/gX/
AOaWvb6KOSX8z/D/ACDnj/Kvx/zPEP8Ahq/48/8ASMr44f8Ag/8AAv8A80tH /DV/x5/6RlfH
D/wf+Bf/AJpa9voo5JfzP8P8g54/yr8f8zxD/hq/48/9Iyvjh/4P/Av/AM0t H/DV/wAef+kZ
Xxw/8H/gX/5pa9voo5JfzP8AD/IOeP8AKvx/zPEP+Gr/AI8/9Iyvjh/4P/Av /wA0tH/DV/x5
/wCkZXxw/wDB/wCBf/mlr2+ijkl/M/w/yDnj/Kvx/wAzxD/hq/48/wDSMr44 f+D/AMC//NLR
/wANX/Hn/pGV8cP/AAf+Bf8A5pa9voo5JfzP8P8AIOeP8q/H/M8Q/wCGr/jz /wBIyvjh/wCD
/wAC/wDzS0f8NX/Hn/pGV8cP/B/4F/8Amlr2+ijkl/M/w/yDnj/Kvx/zPEP+ Gr/jz/0jK+OH
/g/8C/8AzS0f8NX/AB5/6RlfHD/wf+Bf/mlr2+ijkl/M/wAP8g54/wAq/H/M 8Q/4av8Ajz/0
jK+OH/g/8C//ADS1j2/xY8efE/8Aa0/Zo/4Tf9mTxx8OfsPxwvvsv/CZ3+hT /wBob/AHjLd5
P9k6ne7fL2Lu83y8+amzfh9v0PXmHxd/5O0/ZW/7Lhqn/qAeLq5cdGSwk/ee 3l/kdmAnF4yC
5UtfP/M+z6KKK+RPtAr40/b5+IWg/Cv9vD4QePfE9hrl1Y2HwP8AiJ58Hhvw xf6zetv1zwLG
vl2enwzXE2GcFvLjbaoZ2wqsw+y6+UP2sv8AlJH8E/8Ash/xI/8ATx4IrrwN /rcLdzjzC31K
d+x5/wD8PBvgN/0IPxw/8Rk8df8Aymo/4eDfAb/oQfjh/wCIyeOv/lNXt9Ff W2q9193/AAT4
u9Hs/v8A+AeIf8PBvgN/0IPxw/8AEZPHX/ymo/4eDfAb/oQfjh/4jJ46/wDl NXt9FFqvdfd/
wQvR7P7/APgHiH/Dwb4Df9CD8cP/ABGTx1/8pqP+Hg3wG/6EH44f+IyeOv8A 5TV7fRRar3X3
f8EL0ez+/wD4B4h/w8G+A3/Qg/HD/wARk8df/Kaj/h4N8Bv+hB+OH/iMnjr/ AOU1e30UWq91
93/BC9Hs/v8A+AeIf8PBvgN/0IPxw/8AEZPHX/ymo/4eDfAb/oQfjh/4jJ46 /wDlNXt9FFqv
dfd/wQvR7P7/APgHiH/Dwb4Df9CD8cP/ABGTx1/8pqP+Hg3wG/6EH44f+Iye Ov8A5TV7fRRa
r3X3f8EL0ez+/wD4B4h/w8G+A3/Qg/HD/wARk8df/Kaj/h4N8Bv+hB+OH/iM njr/AOU1e30U
Wq9193/BC9Hs/v8A+AeIf8PBvgN/0IPxw/8AEZPHX/ymo/4eDfAb/oQfjh/4 jJ46/wDlNXt9
FFqvdfd/wQvR7P7/APgHiH/Dwb4Df9CD8cP/ABGTx1/8pqP+Hg3wG/6EH44f +IyeOv8A5TV7
fRRar3X3f8EL0ez+/wD4BQ/4JT/8ml6h/wBlw+KX/qf+IKKP+CU//Jpeof8A ZcPil/6n/iCi
vi6v8WXqz7uj/Bj6I9f+Nf7PXwC/aU8K2/gX9oz4HeD/AB/olpqCX9ro3jXw za6raw3SpJGt
wkV1G6LKEllQOBuCyOM4Y58w/wCHTv8AwSy/6Rp/s/8A/hm9D/8AkWvf6KzN TwD/AIdO/wDB
LL/pGn+z/wD+Gb0P/wCRaP8Ah07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/ AIdO/wDBLL/p
Gn+z/wD+Gb0P/wCRaP8Ah07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO /wDBLL/pGn+z
/wD+Gb0P/wCRaP8Ah07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO/wDB LL/pGn+z/wD+
Gb0P/wCRaP8Ah07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO/wDBLL/p Gn+z/wD+Gb0P
/wCRaP8Ah07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO/wDBLL/pGn+z /wD+Gb0P/wCR
aP8Ah07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO/wDBLL/pGn+z/wD+ Gb0P/wCRaP8A
h07/AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO/wDBLL/pGn+z/wD+Gb0P /wCRaP8Ah07/
AMEsv+kaf7P/AP4ZvQ//AJFr3+igDwD/AIdO/wDBLL/pGn+z/wD+Gb0P/wCR a9P+Cn7PXwC/
Zr8K3HgX9nP4HeD/AABol3qD391o3grwza6VazXTJHG1w8VrGiNKUiiQuRuK xoM4UY7CigAo
oooAK8A/4dO/8Esv+kaf7P8A/wCGb0P/AORa9/ooA8A/4dO/8Esv+kaf7P8A /wCGb0P/AORa
P+HTv/BLL/pGn+z/AP8Ahm9D/wDkWvf6KAPAP+HTv/BLL/pGn+z/AP8Ahm9D /wDkWj/h07/w
Sy/6Rp/s/wD/AIZvQ/8A5Fr3+igDwD/h07/wSy/6Rp/s/wD/AIZvQ/8A5Fo/ 4dO/8Esv+kaf
7P8A/wCGb0P/AORa9/ooA8A/4dO/8Esv+kaf7P8A/wCGb0P/AORaP+HTv/BL L/pGn+z/AP8A
hm9D/wDkWvf6KAPAP+HTv/BLL/pGn+z/AP8Ahm9D/wDkWj/h07/wSy/6Rp/s /wD/AIZvQ/8A
5Fr3+igDwD/h07/wSy/6Rp/s/wD/AIZvQ/8A5Fo/4dO/8Esv+kaf7P8A/wCG b0P/AORa9/oo
A8A/4dO/8Esv+kaf7P8A/wCGb0P/AORaP+HTv/BLL/pGn+z/AP8Ahm9D/wDk Wvf6KAPAP+HT
v/BLL/pGn+z/AP8Ahm9D/wDkWj/h07/wSy/6Rp/s/wD/AIZvQ/8A5Fr3+igD wD/h07/wSy/6
Rp/s/wD/AIZvQ/8A5Frf+Fv/AAT2/YF+B3jux+KXwU/Ye+D/AIP8T6X5v9me I/C3w00rT7+0
8yJ4ZPKuILdJI98UkkbbWG5XZTkEivYKKACiiigAryn9or9iz4A/tT+JPDvj P4uaf4qTWPCl
jqFloWq+EPiPrvhu5gtr57R7qBpdIvbZpo5HsbRikhZQ0CkAHOfVqKabTuhN JqzPnD/h1P8A
sl/9DD8cP/EpPH//AMu6P+HU/wCyX/0MPxw/8Sk8f/8Ay7r6Poq/a1f5n95H saP8q+4+cP8A
h1P+yX/0MPxw/wDEpPH/AP8ALuj/AIdT/sl/9DD8cP8AxKTx/wD/AC7r6Poo 9rV/mf3h7Gj/
ACr7j5w/4dT/ALJf/Qw/HD/xKTx//wDLuj/h1P8Asl/9DD8cP/EpPH//AMu6 +j6KPa1f5n94
exo/yr7j5w/4dT/sl/8AQw/HD/xKTx//APLuj/h1P+yX/wBDD8cP/EpPH/8A 8u6+j6KPa1f5
n94exo/yr7j5w/4dT/sl/wDQw/HD/wASk8f/APy7o/4dT/sl/wDQw/HD/wAS k8f/APy7r6Po
o9rV/mf3h7Gj/KvuPnD/AIdT/sl/9DD8cP8AxKTx/wD/AC7o/wCHU/7Jf/Qw /HD/AMSk8f8A
/wAu6+j6KPa1f5n94exo/wAq+4+cP+HU/wCyX/0MPxw/8Sk8f/8Ay7o/4dT/ ALJf/Qw/HD/x
KTx//wDLuvo+ij2tX+Z/eHsaP8q+4+cP+HU/7Jf/AEMPxw/8Sk8f/wDy7o/4 dT/sl/8AQw/H
D/xKTx//APLuvo+ij2tX+Z/eHsaP8q+4+cP+HU/7Jf8A0MPxw/8AEpPH/wD8 u6P+HU/7Jf8A
0MPxw/8AEpPH/wD8u6+j6KPa1f5n94exo/yr7jjfgF8Avhd+zH8LrP4N/BvR r6x0Cxvr+9ii
1PXr3VLmS5vb2e+u55bu+mmuJ5Jbm5nlZ5JGYtIecYAK7Kis9zTY/9k=
--------------040806060903000402090203
Content-Type: text/xml;
name="Covariant.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Covariant.ecore"
<?xml version="1.0" encoding="ISO-8859-1"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Covariant"
nsURI="http://Covariant" nsPrefix="Covariant">
<eClassifiers xsi:type="ecore:EClass" name="Super">
<eStructuralFeatures xsi:type="ecore:EReference" name="ref1" eType="#//Sub1" eOpposite="#//Sub1/op1"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="ref2" eType="#//Sub2" eOpposite="#//Sub2/op2"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="ref3" eType="#//Sub3" eOpposite="#//Sub3/op3"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Sub1">
<eStructuralFeatures xsi:type="ecore:EReference" name="op1" eType="#//Super" eOpposite="#//Super/ref1"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Sub2">
<eStructuralFeatures xsi:type="ecore:EReference" name="op2" eType="#//Super" eOpposite="#//Super/ref2"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Sub3">
<eStructuralFeatures xsi:type="ecore:EReference" name="op3" eType="#//Super" eOpposite="#//Super/ref3"/>
</eClassifiers>
</ecore:EPackage>
--------------040806060903000402090203--
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414728 is a reply to message #414723] |
Tue, 20 November 2007 07:21  |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------090309040904040002040700
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Philipp,
Just so I can understand exactly what question I'm answering, what
methods will Super and Sub1 have in them and what will be their types?
Keep in mind that my likely answer will be, define an EOperation for
each method except the ones that will be generated anyway if you define
a feature whose accessor will produce that desired signature directly.
Container features are always a bit problematic to generate because most
objects can be contained in many places and having an accessor for each
place seems like overkill. I could imagine suppressing the visibility
of the accessors from the API. E.g., you might define "ref" in each
Subx and make the opposite "opx" but then suppress it from being
visible. In Super you get define getOp (to return null), and in each
Subx, you could override it to return getOpx().
Philipp W. Kutter wrote:
> Hi, Ed.
> I read the below post of Marco Pantel and your answer in the ocl group.
> As you suggested, I move the discussion to the EMF group.
>
> I would be interested in the example you give, and get it running.
>
> Thus I have a superclass Super, and three subclasses Sub1, Sub2, Sub3.
>
> Then I have ref1, ref2, ref3 from Super to Sub1, Sub2, Sub3, and every
> subclass has a reference op1, op2, op3 to the superclass, being the
> opposite of its counterpart.
>
> (see screenshot and ecore file)
>
> Now, what do you mean by "provide EOperations in the base that have
> the same matching signature as the feature accessors"
>
>
> Sorry for not getting it immediatly, and thanks for an aditional hint in
> advance.
>
> Best, Philipp
>
>
>
> Ed Merks wrote:
>> Marco,
>>
>> This doesn't really sound like an OCL question. Opposites must be
>> properly paired. You could define "container" to be a derived
>> volatile unchangeable reference in the base and implement it by
>> reusing EObject.eContainer(), which is the implicit opposite of all
>> containment references; the subclass references would then be
>> unidirectional. Or you could define three separate bidirectional
>> references in the derived classes and provide EOperations in the base
>> that have the same matching signature as the feature accessors,
>> taking advantage of Java 5.0's support for covariant return types.
>>
>>
>> Marco Pantel wrote:
>>> Hi everyone!
>>>
>>> I have an abstract superclass and three subclasses of it.
>>> Each of the subclasses has got two EReferences to the superclass.
>>> I declared an EReference "container : superclass" in the superclass.
>>> But now the ecore-editor won't let me choose this
>>> container-reference as
>>> an EOpposite to one of the subclasses' references. It says "The
>>> opposite
>>> must be a feature of the reference's type".
>>>
>>> How can I solve this problem?
>>> Do I have to declare three different types of container-references, one
>>> for each subclass?
>>>
>>>
>>> Regards, Marco
>>>
>
>
> ------------------------------------------------------------ ------------
>
--------------090309040904040002040700
Content-Type: multipart/related;
boundary="------------050004070801040107080703"
--------------050004070801040107080703
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Philipp,<br>
<br>
Just so I can understand exactly what question I'm answering, what
methods will Super and Sub1 have in them and what will be their types?
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414748 is a reply to message #414728] |
Tue, 20 November 2007 10:29 |
| Eclipse User |
|
|
|
Ed Merks wrote:
> Philipp,
>
> Just so I can understand exactly what question I'm answering, what
> methods will Super and Sub1 have in them and what will be their types?
No, idea. You proposed something to Marco in your post that takes
advantage of covariant return types.
I am just asking for the details of YOUR proposal to Marco. My prepared
model was just to save you time, by adding whatever I understood was
already in the discussion. I have no clue, thats why I try to get more
info.
To show me what you meant, you might have to remove the opx references,
thats ok. I just ask for a complete example of what you meant, which
takes advantage of the covariant return types, and which was not
possible prior to EMF 2.3.
I know we already discussed this earlier, and I am always hesitating to
ask for a complete example as your time is limited. If you could extend
what I sent to what you had exactly in mind when speaking to Marco,
would be great.
Best, Philipp
PS: What you write below is clear to me, and I know how to hide setters
and getters in the generated interfaces.
> Keep in mind that my likely answer will be, define an EOperation for
> each method except the ones that will be generated anyway if you define
> a feature whose accessor will produce that desired signature directly.
> Container features are always a bit problematic to generate because most
> objects can be contained in many places and having an accessor for each
> place seems like overkill. I could imagine suppressing the visibility
> of the accessors from the API. E.g., you might define "ref" in each
> Subx and make the opposite "opx" but then suppress it from being
> visible. In Super you get define getOp (to return null), and in each
> Subx, you could override it to return getOpx().
>
>
> Philipp W. Kutter wrote:
>> Hi, Ed.
>> I read the below post of Marco Pantel and your answer in the ocl group.
>> As you suggested, I move the discussion to the EMF group.
>>
>> I would be interested in the example you give, and get it running.
>>
>> Thus I have a superclass Super, and three subclasses Sub1, Sub2, Sub3.
>>
>> Then I have ref1, ref2, ref3 from Super to Sub1, Sub2, Sub3, and every
>> subclass has a reference op1, op2, op3 to the superclass, being the
>> opposite of its counterpart.
>>
>> (see screenshot and ecore file)
>>
>> Now, what do you mean by "provide EOperations in the base that have
>> the same matching signature as the feature accessors"
>>
>>
>> Sorry for not getting it immediatly, and thanks for an aditional hint in
>> advance.
>>
>> Best, Philipp
>>
>>
>>
>> Ed Merks wrote:
>>> Marco,
>>>
>>> This doesn't really sound like an OCL question. Opposites must be
>>> properly paired. You could define "container" to be a derived
>>> volatile unchangeable reference in the base and implement it by
>>> reusing EObject.eContainer(), which is the implicit opposite of all
>>> containment references; the subclass references would then be
>>> unidirectional. Or you could define three separate bidirectional
>>> references in the derived classes and provide EOperations in the base
>>> that have the same matching signature as the feature accessors,
>>> taking advantage of Java 5.0's support for covariant return types.
>>>
>>>
>>> Marco Pantel wrote:
>>>> Hi everyone!
>>>>
>>>> I have an abstract superclass and three subclasses of it.
>>>> Each of the subclasses has got two EReferences to the superclass.
>>>> I declared an EReference "container : superclass" in the superclass.
>>>> But now the ecore-editor won't let me choose this
>>>> container-reference as
>>>> an EOpposite to one of the subclasses' references. It says "The
>>>> opposite
>>>> must be a feature of the reference's type".
>>>>
>>>> How can I solve this problem?
>>>> Do I have to declare three different types of container-references, one
>>>> for each subclass?
>>>>
>>>>
>>>> Regards, Marco
>>>>
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414755 is a reply to message #414748] |
Tue, 20 November 2007 11:45 |
| Eclipse User |
|
|
|
Philipp,
I'll try to find some time, but I have personal issues I have to deal
with right now...
Philipp W. Kutter wrote:
> Ed Merks wrote:
>> Philipp,
>>
>> Just so I can understand exactly what question I'm answering, what
>> methods will Super and Sub1 have in them and what will be their types?
>
> No, idea. You proposed something to Marco in your post that takes
> advantage of covariant return types.
>
> I am just asking for the details of YOUR proposal to Marco. My
> prepared model was just to save you time, by adding whatever I
> understood was already in the discussion. I have no clue, thats why I
> try to get more
> info.
>
> To show me what you meant, you might have to remove the opx
> references, thats ok. I just ask for a complete example of what you
> meant, which takes advantage of the covariant return types, and which
> was not possible prior to EMF 2.3.
>
> I know we already discussed this earlier, and I am always hesitating
> to ask for a complete example as your time is limited. If you could
> extend what I sent to what you had exactly in mind when speaking to
> Marco, would be great.
>
> Best, Philipp
>
> PS: What you write below is clear to me, and I know how to hide
> setters and getters in the generated interfaces.
>
>> Keep in mind that my likely answer will be, define an EOperation for
>> each method except the ones that will be generated anyway if you
>> define a feature whose accessor will produce that desired signature
>> directly. Container features are always a bit problematic to
>> generate because most objects can be contained in many places and
>> having an accessor for each place seems like overkill. I could
>> imagine suppressing the visibility of the accessors from the API.
>> E.g., you might define "ref" in each Subx and make the opposite "opx"
>> but then suppress it from being visible. In Super you get define
>> getOp (to return null), and in each Subx, you could override it to
>> return getOpx().
>>
>> Philipp W. Kutter wrote:
>>> Hi, Ed.
>>> I read the below post of Marco Pantel and your answer in the ocl group.
>>> As you suggested, I move the discussion to the EMF group.
>>>
>>> I would be interested in the example you give, and get it running.
>>>
>>> Thus I have a superclass Super, and three subclasses Sub1, Sub2, Sub3.
>>>
>>> Then I have ref1, ref2, ref3 from Super to Sub1, Sub2, Sub3, and
>>> every subclass has a reference op1, op2, op3 to the superclass,
>>> being the opposite of its counterpart.
>>>
>>> (see screenshot and ecore file)
>>>
>>> Now, what do you mean by "provide EOperations in the base that have
>>> the same matching signature as the feature accessors"
>>>
>>>
>>> Sorry for not getting it immediatly, and thanks for an aditional
>>> hint in
>>> advance.
>>>
>>> Best, Philipp
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Marco,
>>>>
>>>> This doesn't really sound like an OCL question. Opposites must be
>>>> properly paired. You could define "container" to be a derived
>>>> volatile unchangeable reference in the base and implement it by
>>>> reusing EObject.eContainer(), which is the implicit opposite of all
>>>> containment references; the subclass references would then be
>>>> unidirectional. Or you could define three separate bidirectional
>>>> references in the derived classes and provide EOperations in the
>>>> base that have the same matching signature as the feature
>>>> accessors, taking advantage of Java 5.0's support for covariant
>>>> return types.
>>>>
>>>>
>>>> Marco Pantel wrote:
>>>>> Hi everyone!
>>>>>
>>>>> I have an abstract superclass and three subclasses of it.
>>>>> Each of the subclasses has got two EReferences to the superclass.
>>>>> I declared an EReference "container : superclass" in the superclass.
>>>>> But now the ecore-editor won't let me choose this
>>>>> container-reference as
>>>>> an EOpposite to one of the subclasses' references. It says "The
>>>>> opposite
>>>>> must be a feature of the reference's type".
>>>>>
>>>>> How can I solve this problem?
>>>>> Do I have to declare three different types of
>>>>> container-references, one
>>>>> for each subclass?
>>>>>
>>>>>
>>>>> Regards, Marco
>>>>>
>>>
>>>
>>> ------------------------------------------------------------ ------------
>>>
>>>
>>
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414758 is a reply to message #414748] |
Tue, 20 November 2007 12:16 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
Perhaps I can jump in with a small example to answer your question, below.
EMF allows an EClass to declare EOperations that have the same signature as
the Java getter and setter methods that will be generated for access to
EStructuralFeatures.
So, for example, you can define:
EClass Seed
EClass Fruit
seed : Seed [0..*]
EClass Tree
fruit : ? extends Fruit [0..*]
getFruit() : ? extends Fruit [0..*]
addFruit(f : Fruit)
removeFruit(f : Fruit)
EClass OrchardFruit -> Fruit
peopleLikeIt : boolean
EClass OrchardTree -> Tree
getFruit() : ? extends OrchardFruit [0..*] // covariant return
EClass Cone -> Fruit
squirrelsLikeIt : boolean
EClass Conifer -> Tree
getFruit() : ? extends Cone [0..*] // covariant return
Clients of the generated API can then use the getFruit() method and see
return type covariant the specializations of Tree. e.g.,
OrchardTree orangeTree = ... ;
Conifer redPine = ... ;
EList<? extends Fruit> fruits;
EList<? extends Cone> cones;
fruits = redPine.getFruit(); // OK
fruits = orangeTree.getFruit(); // OK
cones = redPine.getFruit(); // OK
cones = orangeTree.getFruit(); // Compile Error
This example uses multi-valued references, for which covariant returns
require the bounded wildcards. This makes it awkward for features that are
supposed to be writable, which can be addressed by the add/remove
operations. The situation is simpler for scalar reference features.
HTH,
Christian
Philipp W. Kutter wrote:
-----8<-----
>>> Now, what do you mean by "provide EOperations in the base that have
>>> the same matching signature as the feature accessors"
----->8-----
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414958 is a reply to message #414758] |
Mon, 26 November 2007 10:22 |
| Eclipse User |
|
|
|
Hi, Christian.
Thanks for the answer. Can you send me the Ecore file of your example?
I have plenty of questions, but I think it's faster if I look at the
ECore, and ask then.
Best, Philipp
Christian W. Damus wrote:
> Hi, Philipp,
>
> Perhaps I can jump in with a small example to answer your question, below.
>
> EMF allows an EClass to declare EOperations that have the same signature as
> the Java getter and setter methods that will be generated for access to
> EStructuralFeatures.
>
> So, for example, you can define:
>
> EClass Seed
>
> EClass Fruit
> seed : Seed [0..*]
>
> EClass Tree
> fruit : ? extends Fruit [0..*]
> getFruit() : ? extends Fruit [0..*]
> addFruit(f : Fruit)
> removeFruit(f : Fruit)
>
> EClass OrchardFruit -> Fruit
> peopleLikeIt : boolean
>
> EClass OrchardTree -> Tree
> getFruit() : ? extends OrchardFruit [0..*] // covariant return
>
> EClass Cone -> Fruit
> squirrelsLikeIt : boolean
>
> EClass Conifer -> Tree
> getFruit() : ? extends Cone [0..*] // covariant return
>
> Clients of the generated API can then use the getFruit() method and see
> return type covariant the specializations of Tree. e.g.,
>
> OrchardTree orangeTree = ... ;
> Conifer redPine = ... ;
>
> EList<? extends Fruit> fruits;
> EList<? extends Cone> cones;
>
> fruits = redPine.getFruit(); // OK
> fruits = orangeTree.getFruit(); // OK
> cones = redPine.getFruit(); // OK
> cones = orangeTree.getFruit(); // Compile Error
>
> This example uses multi-valued references, for which covariant returns
> require the bounded wildcards. This makes it awkward for features that are
> supposed to be writable, which can be addressed by the add/remove
> operations. The situation is simpler for scalar reference features.
>
> HTH,
>
> Christian
>
>
> Philipp W. Kutter wrote:
>
> -----8<-----
>
>>>> Now, what do you mean by "provide EOperations in the base that have
>>>> the same matching signature as the feature accessors"
>
> ----->8-----
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414963 is a reply to message #414958] |
Mon, 26 November 2007 11:09 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
Sorry, I don't have an Ecore variant of this example because, as it turns
out, it cannot be constructed. Ecore doesn't permit wildcard types
(bounded or otherwise) as the types of multiplicity-many
EStructuralFeatures or EOperations.
So, I guess this example is void. I should have tried it with Ecore, first,
instead of my ad hoc textual notation.
cW
Philipp W. Kutter wrote:
> Hi, Christian.
> Thanks for the answer. Can you send me the Ecore file of your example?
>
> I have plenty of questions, but I think it's faster if I look at the
> ECore, and ask then.
>
> Best, Philipp
>
> Christian W. Damus wrote:
>> Hi, Philipp,
>>
>> Perhaps I can jump in with a small example to answer your question,
>> below.
>>
>> EMF allows an EClass to declare EOperations that have the same signature
>> as the Java getter and setter methods that will be generated for access
>> to EStructuralFeatures.
>>
>> So, for example, you can define:
>>
>> EClass Seed
>>
>> EClass Fruit
>> seed : Seed [0..*]
>>
>> EClass Tree
>> fruit : ? extends Fruit [0..*]
>> getFruit() : ? extends Fruit [0..*]
>> addFruit(f : Fruit)
>> removeFruit(f : Fruit)
>>
>> EClass OrchardFruit -> Fruit
>> peopleLikeIt : boolean
>>
>> EClass OrchardTree -> Tree
>> getFruit() : ? extends OrchardFruit [0..*] // covariant return
>>
>> EClass Cone -> Fruit
>> squirrelsLikeIt : boolean
>>
>> EClass Conifer -> Tree
>> getFruit() : ? extends Cone [0..*] // covariant return
>>
>> Clients of the generated API can then use the getFruit() method and see
>> return type covariant the specializations of Tree. e.g.,
>>
>> OrchardTree orangeTree = ... ;
>> Conifer redPine = ... ;
>>
>> EList<? extends Fruit> fruits;
>> EList<? extends Cone> cones;
>>
>> fruits = redPine.getFruit(); // OK
>> fruits = orangeTree.getFruit(); // OK
>> cones = redPine.getFruit(); // OK
>> cones = orangeTree.getFruit(); // Compile Error
>>
>> This example uses multi-valued references, for which covariant returns
>> require the bounded wildcards. This makes it awkward for features that
>> are supposed to be writable, which can be addressed by the add/remove
>> operations. The situation is simpler for scalar reference features.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Philipp W. Kutter wrote:
>>
>> -----8<-----
>>
>>>>> Now, what do you mean by "provide EOperations in the base that have
>>>>> the same matching signature as the feature accessors"
>>
>> ----->8-----
|
|
| |
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414967 is a reply to message #414965] |
Tue, 27 November 2007 02:14 |
| Eclipse User |
|
|
|
Hi, Christian.
I started to look at your example.
When I try to reload the ECore from your generted Java, I get errors:
- Analysis result for the instance type name '? extends Cone'
- - The '?' at index 0 is not expected
- Analysis result for the instance type name '? extends OrchardFruit'
- - The '?' at index 0 is not expected
- Analysis result for the instance type name '? extends Fruit'
- - The '?' at index 0 is not expected
This together with the CodeGen error you mention may be indications that
we do something not intended here. I am just trying to understand.
Another thing I did is I removed the getFruit operation from the Tree
class. I then regenerated the code, and I had no duplicate getFruit().
Is there a reason you put the getFruit operation in addition to the
fruit attribute?
After removing the getFruit operation, the Ecore model is still valid.
The example looks now, as if we could override the meaning of
attributes/references using EOperations having by coincidence the same
name. Is this clean? Would we not rather need an error, that this
results in duplicate methods?
In any case, I learn from the example that we can define overriding
operations in ECore. And that overriding just does not work for
attributes/references, except if we use the above trick with operations.
What makes me real unhappy here is that we have fruit as attribute,
rather than reference. In all our use scenarios of EMF, the
visualization of references as arrows in EMF diagrams is key. This is
lost here.
Best, Philipp
Christian W. Damus wrote:
> Hi, Philipp,
>
> Actually, I was wrong and Ed set me straight.
>
> Attached is an Ecore version of the orchard example with the code generated.
>
> The tricky bit is to declare the "fruit" property as an EAttribute using the
> EEList<? extends Fruit> data type. Likewise, the return type of the
> EOperations.
>
> A couple of notes:
>
> - in the generated code, I had to delete the duplicate definition of the
> getFruit() operation. I think this may be a codegen bug
> - in the generated code, I had errors in the OrchardTreeImpl and
> ConiferImpl classes until I define the implementations of their
> specialized getFruit() operations. This does not look like an EMF bug
>
> HTH,
>
> Christian
>
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414970 is a reply to message #414967] |
Tue, 27 November 2007 07:07 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------020209080708050107090103
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Philipp,
Comments below; note that I've not looked at the context of your
question, just the local details here.
Philipp W. Kutter wrote:
> Hi, Christian.
> I started to look at your example.
>
> When I try to reload the ECore from your generted Java, I get errors:
> - Analysis result for the instance type name '? extends Cone'
> - - The '?' at index 0 is not expected
> - Analysis result for the instance type name '? extends OrchardFruit'
> - - The '?' at index 0 is not expected
> - Analysis result for the instance type name '? extends Fruit'
> - - The '?' at index 0 is not expected
In general, EMF only allows wildcards to appear in the context of the
type arguments of a containing generic type; Java has the same
restriction. So while java.util.List<? extends a.b.Xyz> is a well
formed instance type name, just "? extends a.b.Xyz" all by itself is
not. As such, a wildcard cannot directly be the type of any typed
element and cannot directly be the instance type name of a classifier.
>
> This together with the CodeGen error you mention may be indications that
> we do something not intended here. I am just trying to understand.
>
>
> Another thing I did is I removed the getFruit operation from the Tree
> class. I then regenerated the code, and I had no duplicate getFruit().
I'm not sure the context, but perhaps something isn't quite right with
the generator's filtering of operations whose signature collides with
that of a feature's accessor. If there is a simple example of this
problem I can look at fixing it...
>
> Is there a reason you put the getFruit operation in addition to the
> fruit attribute?
>
> After removing the getFruit operation, the Ecore model is still valid.
> The example looks now, as if we could override the meaning of
> attributes/references using EOperations having by coincidence the same
> name. Is this clean? Would we not rather need an error, that this
> results in duplicate methods?
You could imagine an interface that defines operations with certain
signatures and then having a class that implements those operation by
virtue of having a feature that generates methods with the same
signature as the declared operations. EMF should properly detect the
collision and avoid generating duplicates as well as avoid generating an
override with a // TODO in it.
>
>
>
> In any case, I learn from the example that we can define overriding
> operations in ECore. And that overriding just does not work for
> attributes/references, except if we use the above trick with operations.
Yes, it's best to think of features as being like variables/fields.
I.e., you can declare them but there's no way to override them by
redeclaring them in a derived class. You can only declare duplicates
that will cause you problems when you try to provide access to both via
a single set of accessor methods. Operations on the other hand are just
like Java methods and should support overloading and even overriding.
In general though, we avoid generating an override in the implementing
class if the method is already implemented in a base class because that
generated body will just be a // TODO. We could probably do a better
job detecting if there is a body annotation on the method indicating it
really is intended to be an override with a different implementation.
But no one has opened a feature request with a meaningful example of
this yet (despite prompting).
>
>
>
> What makes me real unhappy here is that we have fruit as attribute,
> rather than reference. In all our use scenarios of EMF, the
> visualization of references as arrows in EMF diagrams is key. This is
> lost here.
I probably should understand the context a bit better. Likely this is
related to Christian's questions yesterday of wanting to define a
feature whose type is directly a bounded wildcard. As I said at the
start, this is not supported. It would only make some sense if the
feature were a multiplicity many and was unchangeable, which likely also
implies it must be transient and must be derived, which implies writing
some code by hand to make it all work. It's certainly possible to
modify the signature to make the type be a bounded wildcard but I'm not
keen on the idea of complicating Ecore to handle what to me seems like a
dark corner case:
interface X
{
List<? extends X> getFoo();
}
class XImpl implements X
{
List<X> foo;
public List<X> getFoo()
{
if (foo == null)
{
foo = new ArrayList<X>();
}
return foo;
}
}
In theory at least, it should be possible to achieve this result
directly by defining an operation with the given signature for the
interface and suppressing the getter from the interface. (In practice
this might well be a case we've never tested; bugzillas with simple test
cases are welcome).
> Best, Philipp
>
>
>
>
>
>
>
>
> Christian W. Damus wrote:
>> Hi, Philipp,
>>
>> Actually, I was wrong and Ed set me straight.
>>
>> Attached is an Ecore version of the orchard example with the code
>> generated.
>>
>> The tricky bit is to declare the "fruit" property as an EAttribute
>> using the
>> EEList<? extends Fruit> data type. Likewise, the return type of the
>> EOperations.
>>
>> A couple of notes:
>>
>> - in the generated code, I had to delete the duplicate definition
>> of the
>> getFruit() operation. I think this may be a codegen bug
>> - in the generated code, I had errors in the OrchardTreeImpl and
>> ConiferImpl classes until I define the implementations of their
>> specialized getFruit() operations. This does not look like an
>> EMF bug
>>
>> HTH,
>>
>> Christian
>>
--------------020209080708050107090103
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Philipp,<br>
<br>
Comments below; note that I've not looked at the context of your
question, just the local details here.<br>
<br>
Philipp W. Kutter wrote:
<blockquote cite="mid:figg2c$afu$1@build.eclipse.org" type="cite">Hi,
Christian.
<br>
I started to look at your example.
<br>
<br>
When I try to reload the ECore from your generted Java, I get errors:
<br>
- Analysis result for the instance type name '? extends Cone'
<br>
- - The '?' at index 0 is not expected
<br>
- Analysis result for the instance type name '? extends OrchardFruit'
<br>
- - The '?' at index 0 is not expected
<br>
- Analysis result for the instance type name '? extends Fruit'
<br>
- - The '?' at index 0 is not expected
<br>
</blockquote>
In general, EMF only allows wildcards to appear in the context of the
type arguments of a containing generic type; Java has the same
restriction. So while java.util.List<? extends a.b.Xyz> is a
well formed instance type name, just "? extends a.b.Xyz" all by itself
is not. As such, a wildcard cannot directly be the type of any typed
element and cannot directly be the instance type name of a classifier.<br>
<blockquote cite="mid:figg2c$afu$1@build.eclipse.org" type="cite"><br>
This together with the CodeGen error you mention may be indications
that
<br>
we do something not intended here. I am just trying to understand.
<br>
<br>
<br>
Another thing I did is I removed the getFruit operation from the Tree
class. I then regenerated the code, and I had no duplicate getFruit().
<br>
</blockquote>
I'm not sure the context, but perhaps something isn't quite right with
the generator's filtering of operations whose signature collides with
that of a feature's accessor. If there is a simple example of this
problem I can look at fixing it...<br>
<blockquote cite="mid:figg2c$afu$1@build.eclipse.org" type="cite"><br>
Is there a reason you put the getFruit operation in addition to the
fruit attribute?
<br>
<br>
After removing the getFruit operation, the Ecore model is still valid.
<br>
The example looks now, as if we could override the meaning of
attributes/references using EOperations having by coincidence the same
<br>
name. Is this clean? Would we not rather need an error, that this
results in duplicate methods?
<br>
</blockquote>
You could imagine an interface that defines operations with certain
signatures and then having a class that implements those operation by
virtue of having a feature that generates methods with the same
signature as the declared operations. EMF should properly detect the
collision and avoid generating duplicates as well as avoid generating
an override with a // TODO in it.<br>
<blockquote cite="mid:figg2c$afu$1@build.eclipse.org" type="cite"><br>
<br>
<br>
In any case, I learn from the example that we can define overriding
operations in ECore. And that overriding just does not work for
attributes/references, except if we use the above trick with
operations.
<br>
</blockquote>
Yes, it's best to think of features as being like variables/fields.
I.e., you can declare them but there's no way to override them by
redeclaring them in a derived class. You can only declare duplicates
that will cause you problems when you try to provide access to both via
a single set of accessor methods. Operations on the other hand are
just like Java methods and should support overloading and even
overriding. In general though, we avoid generating an override in the
implementing class if the method is already implemented in a base class
because that generated body will just be a // TODO. We could probably
do a better job detecting if there is a body annotation on the method
indicating it really is intended to be an override with a different
implementation. But no one has opened a feature request with a
meaningful example of this yet (despite prompting).<br>
<blockquote cite="mid:figg2c$afu$1@build.eclipse.org" type="cite"><br>
<br>
<br>
What makes me real unhappy here is that we have fruit as attribute,
rather than reference. In all our use scenarios of EMF, the
visualization of references as arrows in EMF diagrams is key. This is
lost here.
<br>
</blockquote>
I probably should understand the context a bit better. Likely this is
related to Christian's questions yesterday of wanting to define a
feature whose type is directly a bounded wildcard. As I said at the
start, this is not supported. It would only make some sense if the
feature were a multiplicity many and was unchangeable, which likely
also implies it must be transient and must be derived, which implies
writing some code by hand to make it all work. It's certainly possible
to modify the signature to make the type be a bounded wildcard but I'm
not keen on the idea of complicating Ecore to handle what to me seems
like a dark corner case:<br>
<blockquote><small> interface X</small><br>
<small> {</small><br>
<small> List<? extends X> getFoo(); </small><br>
<small> }</small><br>
<small> </small><br>
<small> class XImpl implements X</small><br>
<small> {</small><br>
<small> List<X> foo;</small><br>
<small> </small><br>
<small> public List<X> getFoo()</small><br>
<small> {</small><br>
<small> if (foo == null)</small><br>
<small> {</small><br>
<small> foo = new ArrayList<X>();</small><br>
<small> }</small><br>
<small> return foo;</small><br>
<small> }</small><br>
<small> }</small><br>
</blockquote>
In theory at least, it should be possible to achieve this result
directly by defining an operation with the given signature for the
interface and suppressing the getter from the interface. (In practice
this might well be a case we've never tested; bugzillas with simple
test cases are welcome).<br>
<blockquote cite="mid:figg2c$afu$1@build.eclipse.org" type="cite">Best,
Philipp
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Christian W. Damus wrote:
<br>
<blockquote type="cite">Hi, Philipp,
<br>
<br>
Actually, I was wrong and Ed set me straight.
<br>
<br>
Attached is an Ecore version of the orchard example with the code
generated.
<br>
<br>
The tricky bit is to declare the "fruit" property as an EAttribute
using the
<br>
EEList<? extends Fruit> data type. Likewise, the return type of
the
<br>
EOperations.
<br>
<br>
A couple of notes:
<br>
<br>
- in the generated code, I had to delete the duplicate definition of
the
<br>
getFruit() operation. I think this may be a codegen bug
<br>
- in the generated code, I had errors in the OrchardTreeImpl and
<br>
ConiferImpl classes until I define the implementations of their
<br>
specialized getFruit() operations. This does not look like an EMF
bug
<br>
<br>
HTH,
<br>
<br>
Christian
<br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------020209080708050107090103--
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414974 is a reply to message #414967] |
Tue, 27 November 2007 07:47 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
See some replies in-line, below.
Cheers,
Christian
Philipp W. Kutter wrote:
> Hi, Christian.
> I started to look at your example.
>
> When I try to reload the ECore from your generted Java, I get errors:
> - Analysis result for the instance type name '? extends Cone'
> - - The '?' at index 0 is not expected
> - Analysis result for the instance type name '? extends OrchardFruit'
> - - The '?' at index 0 is not expected
> - Analysis result for the instance type name '? extends Fruit'
> - - The '?' at index 0 is not expected
Hmmm ... I don't get those when I created the GenModel from the Ecore model,
so it looks to me like a bug in the Java importer. My understanding of
things is that declaring an ETypedElement's type as EEList<? extends Fruit>
is supported.
> This together with the CodeGen error you mention may be indications that
> we do something not intended here. I am just trying to understand.
>
>
> Another thing I did is I removed the getFruit operation from the Tree
> class. I then regenerated the code, and I had no duplicate getFruit().
>
> Is there a reason you put the getFruit operation in addition to the
> fruit attribute?
This was the purpose of the example: to demonstrate how an EOperation can
coincide with the accessor of an EStructuralFeature, and then be redefined
in subtypes using J2SE 5.0's support for covariant returns. Note that I am
not a fan of covariant returns in Java for various reasons.
> After removing the getFruit operation, the Ecore model is still valid.
Yes, it would be.
> The example looks now, as if we could override the meaning of
> attributes/references using EOperations having by coincidence the same
> name. Is this clean? Would we not rather need an error, that this
> results in duplicate methods?
Again, that was the point of the example! Whether it's clean or not depends
on how you want the generated API to look, I suppose.
> In any case, I learn from the example that we can define overriding
> operations in ECore. And that overriding just does not work for
> attributes/references, except if we use the above trick with operations.
>
>
>
> What makes me real unhappy here is that we have fruit as attribute,
> rather than reference. In all our use scenarios of EMF, the
> visualization of references as arrows in EMF diagrams is key. This is
> lost here.
Yes, but this is only because I wanted to demonstrate covariant returns, and
that only works with wildcards when using collection types. Multivalued
features are usually more interesting. If "fruit" were a scalar
EReference, you could do something like:
EClass Tree
fruit : Fruit [0..1]
getFruit() : Fruit [0..1]
EClass Conifer -> Tree
getFruit() : Cone [0..1]
The problem is, that if it's a multiplicity-many EReference, the type cannot
be a wildcard, but then you don't get covariance:
EClass Tree
fruit : Fruit [0..*]
getFruit() : Fruit [0..*]
EClass Conifer -> Tree
getFruit() : Cone [0..*]
// error: EList<Cone> is not compatible with EList<Fruit>
Your other option, which is probably more natural anyway, is to use
generics:
EClass Tree<F extends Fruit>
fruit : F [0..*]
getFruit() : Fruit [0..*]
EClass Conifer -> Tree<Cone>
getFruit() : Cone [0..*]
but, this isn't an example of covariant return types, because binding Cone
to the type parameter F gives *the same* "EList<F> getFruit()" method in
the Conifer class an effective signature of "EList<Cone> getFruit()" even
without the redefinition in the Conifer class. So, it's quite a different
case.
> Best, Philipp
-----8<-----
|
|
| |
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414985 is a reply to message #414974] |
Tue, 27 November 2007 09:42 |
| Eclipse User |
|
|
|
Hi, Christian.
Thanks for the detailed answers. I learned a lot from your example.
However I think I found the most natural example, which is exactly what
I looked for.
I'll submit it for Ed's comments in a separate thread, if you agree.
Best, Philipp
Christian W. Damus wrote:
> Hi, Philipp,
>
> See some replies in-line, below.
>
> Cheers,
>
> Christian
>
> Philipp W. Kutter wrote:
>
>> Hi, Christian.
>> I started to look at your example.
>>
>> When I try to reload the ECore from your generted Java, I get errors:
>> - Analysis result for the instance type name '? extends Cone'
>> - - The '?' at index 0 is not expected
>> - Analysis result for the instance type name '? extends OrchardFruit'
>> - - The '?' at index 0 is not expected
>> - Analysis result for the instance type name '? extends Fruit'
>> - - The '?' at index 0 is not expected
>
> Hmmm ... I don't get those when I created the GenModel from the Ecore model,
> so it looks to me like a bug in the Java importer. My understanding of
> things is that declaring an ETypedElement's type as EEList<? extends Fruit>
> is supported.
>
>
>> This together with the CodeGen error you mention may be indications that
>> we do something not intended here. I am just trying to understand.
>>
>>
>> Another thing I did is I removed the getFruit operation from the Tree
>> class. I then regenerated the code, and I had no duplicate getFruit().
>>
>> Is there a reason you put the getFruit operation in addition to the
>> fruit attribute?
>
> This was the purpose of the example: to demonstrate how an EOperation can
> coincide with the accessor of an EStructuralFeature, and then be redefined
> in subtypes using J2SE 5.0's support for covariant returns. Note that I am
> not a fan of covariant returns in Java for various reasons.
>
>
>> After removing the getFruit operation, the Ecore model is still valid.
>
> Yes, it would be.
>
>
>> The example looks now, as if we could override the meaning of
>> attributes/references using EOperations having by coincidence the same
>> name. Is this clean? Would we not rather need an error, that this
>> results in duplicate methods?
>
> Again, that was the point of the example! Whether it's clean or not depends
> on how you want the generated API to look, I suppose.
>
>
>> In any case, I learn from the example that we can define overriding
>> operations in ECore. And that overriding just does not work for
>> attributes/references, except if we use the above trick with operations.
>>
>>
>>
>> What makes me real unhappy here is that we have fruit as attribute,
>> rather than reference. In all our use scenarios of EMF, the
>> visualization of references as arrows in EMF diagrams is key. This is
>> lost here.
>
> Yes, but this is only because I wanted to demonstrate covariant returns, and
> that only works with wildcards when using collection types. Multivalued
> features are usually more interesting. If "fruit" were a scalar
> EReference, you could do something like:
>
> EClass Tree
> fruit : Fruit [0..1]
> getFruit() : Fruit [0..1]
>
> EClass Conifer -> Tree
> getFruit() : Cone [0..1]
>
> The problem is, that if it's a multiplicity-many EReference, the type cannot
> be a wildcard, but then you don't get covariance:
>
> EClass Tree
> fruit : Fruit [0..*]
> getFruit() : Fruit [0..*]
>
> EClass Conifer -> Tree
> getFruit() : Cone [0..*]
> // error: EList<Cone> is not compatible with EList<Fruit>
>
> Your other option, which is probably more natural anyway, is to use
> generics:
>
> EClass Tree<F extends Fruit>
> fruit : F [0..*]
> getFruit() : Fruit [0..*]
>
> EClass Conifer -> Tree<Cone>
> getFruit() : Cone [0..*]
>
> but, this isn't an example of covariant return types, because binding Cone
> to the type parameter F gives *the same* "EList<F> getFruit()" method in
> the Conifer class an effective signature of "EList<Cone> getFruit()" even
> without the redefinition in the Conifer class. So, it's quite a different
> case.
>
>
>> Best, Philipp
>
> -----8<-----
|
|
|
| Re: taking advantage of Java 5.0's support for covariant return types. [message #414987 is a reply to message #414985] |
Tue, 27 November 2007 09:59 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
Yes, I think it does make more sense that an EOperation in a general type is
"coincidentally" implemented by an accessor for a property of a specialized
type.
In fact, now that you mention it, that is exactly the scenario that I had
trouble remembering in which I first noticed that EMF omitted the stub for
the EOperation in the Impl-class when the property accessor could provide
it.
Sorry for taking you so far down another (dark) alley!
cW
Philipp W. Kutter wrote:
> Hi, Christian.
> Thanks for the detailed answers. I learned a lot from your example.
>
> However I think I found the most natural example, which is exactly what
> I looked for.
>
> I'll submit it for Ed's comments in a separate thread, if you agree.
>
> Best, Philipp
-----8<-----
|
|
|
Goto Forum:
Current Time: Sun Jul 06 09:55:58 EDT 2025
Powered by FUDForum. Page generated in 0.06079 seconds |
Home