Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO 3.0 dependency on Helios
CDO 3.0 dependency on Helios [message #504462] Sat, 19 December 2009 12:41 Go to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-Schwartz
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Eike,

What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6 does have such a dependency, are you looking to keep CDO 3.0 clean of these or do you suspect that you will have to pick them up before 3.0 is complete?

Thanks,
Joel
Re: CDO 3.0 dependency on Helios [message #504463 is a reply to message #504462] Sat, 19 December 2009 13:20 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Hi Joel,

I don't foresee a need to change the lower bound of our dependency
ranges, but we'll continue to develop and test against Platform 3.6 and
EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
I'm currently not 100% sure that CDO continues to function well with pre
M4 EMF, but I believe it ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Joel Rosi-Schwartz schrieb:
> Hi Eike,
>
> What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
> does have such a dependency, are you looking to keep CDO 3.0 clean of
> these or do you suspect that you will have to pick them up before 3.0
> is complete?
>
> Thanks,
> Joel
Re: CDO 3.0 dependency on Helios [message #504478 is a reply to message #504463] Sun, 20 December 2009 01:14 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-Schwartz
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Eike,

No, I wasn't aware that the EObject API was broke in M4. Can you point me towards a conversation about it?

The reason I asked the question originally is that I have to make a decision if ORMF it going to be dependent on Helios or keep it Galileo. At the moment using OCL is my single "excuse" for wanting to move forward. But on the other hand I have to acknowledge that moving forward has the risk of making adoption more challenging.

Joel


Eike Stepper wrote on Sat, 19 December 2009 18:20
Hi Joel,

I don't foresee a need to change the lower bound of our dependency
ranges, but we'll continue to develop and test against Platform 3.6 and
EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
I'm currently not 100% sure that CDO continues to function well with pre
M4 EMF, but I believe it Wink

Cheers
/Eike


Re: CDO 3.0 dependency on Helios [message #504479 is a reply to message #504463] Sun, 20 December 2009 06:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
Eike,

Note that adding methods to EObject isn't breaking the API because
EObject should not be implemented directly by clients.

If we make progress on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706 it's likely you'll
be increasing the lower bound for CDO...


Eike Stepper wrote:
> Hi Joel,
>
> I don't foresee a need to change the lower bound of our dependency
> ranges, but we'll continue to develop and test against Platform 3.6 and
> EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
> I'm currently not 100% sure that CDO continues to function well with pre
> M4 EMF, but I believe it ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Joel Rosi-Schwartz schrieb:
>
>> Hi Eike,
>>
>> What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
>> does have such a dependency, are you looking to keep CDO 3.0 clean of
>> these or do you suspect that you will have to pick them up before 3.0
>> is complete?
>>
>> Thanks,
>> Joel
>>
Re: CDO 3.0 dependency on Helios [message #504481 is a reply to message #504478] Sun, 20 December 2009 06:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
Joel,

We didn't break any APIs. We added eInvoke to EObject:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469


Joel Rosi-Schwartz wrote:
> Hi Eike,
>
> No, I wasn't aware that the EObject API was broke in M4. Can you point
> me towards a conversation about it?
>
> The reason I asked the question originally is that I have to make a
> decision if ORMF it going to be dependent on Helios or keep it
> Galileo. At the moment using OCL is my single "excuse" for wanting to
> move forward. But on the other hand I have to acknowledge that moving
> forward has the risk of making adoption more challenging.
>
> Joel
>
>
> Eike Stepper wrote on Sat, 19 December 2009 18:20
>> Hi Joel,
>>
>> I don't foresee a need to change the lower bound of our dependency
>> ranges, but we'll continue to develop and test against Platform 3.6 and
>> EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
>> I'm currently not 100% sure that CDO continues to function well with pre
>> M4 EMF, but I believe it ;)
>>
>> Cheers
>> /Eike
>
>
Re: CDO 3.0 dependency on Helios [message #504483 is a reply to message #504479] Sun, 20 December 2009 07:16 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> Note that adding methods to EObject isn't breaking the API because
> EObject should not be implemented directly by clients.
I have to because there was no DelegatingEObjectImpl available. Would it
be a good idea to add one now?

> If we make progress on
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706 it's likely
> you'll be increasing the lower bound for CDO...
I know ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
>
> Eike Stepper wrote:
>> Hi Joel,
>>
>> I don't foresee a need to change the lower bound of our dependency
>> ranges, but we'll continue to develop and test against Platform 3.6 and
>> EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
>> I'm currently not 100% sure that CDO continues to function well with pre
>> M4 EMF, but I believe it ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Joel Rosi-Schwartz schrieb:
>>
>>> Hi Eike,
>>>
>>> What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
>>> does have such a dependency, are you looking to keep CDO 3.0 clean of
>>> these or do you suspect that you will have to pick them up before 3.0
>>> is complete?
>>>
>>> Thanks,
>>> Joel
Re: CDO 3.0 dependency on Helios [message #504490 is a reply to message #504483] Sun, 20 December 2009 05:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010801050307080406030008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

I'm not sure what a DelegatingEObjectImpl would be/do nor why it
couldn't extend BasicEObjectImpl.


Eike Stepper wrote:
> Ed Merks schrieb:
>
>> Eike,
>>
>> Note that adding methods to EObject isn't breaking the API because
>> EObject should not be implemented directly by clients.
>>
> I have to because there was no DelegatingEObjectImpl available. Would it
> be a good idea to add one now?
>
>
>> If we make progress on
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706 it's likely
>> you'll be increasing the lower bound for CDO...
>>
> I know ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>> Eike Stepper wrote:
>>
>>> Hi Joel,
>>>
>>> I don't foresee a need to change the lower bound of our dependency
>>> ranges, but we'll continue to develop and test against Platform 3.6 and
>>> EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
>>> I'm currently not 100% sure that CDO continues to function well with pre
>>> M4 EMF, but I believe it ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>> Joel Rosi-Schwartz schrieb:
>>>
>>>
>>>> Hi Eike,
>>>>
>>>> What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
>>>> does have such a dependency, are you looking to keep CDO 3.0 clean of
>>>> these or do you suspect that you will have to pick them up before 3.0
>>>> is complete?
>>>>
>>>> Thanks,
>>>> Joel
>>>>

--------------010801050307080406030008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!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">
Eike,<br>
<br>
I'm not sure what a DelegatingEObjectImpl would be/do nor why it
couldn't extend BasicEObjectImpl.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:hgl4ik$49b$1@build.eclipse.org" type="cite">
<pre wrap="">Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Eike,

Note that adding methods to EObject isn't breaking the API because
EObject should not be implemented directly by clients.
</pre>
</blockquote>
<pre wrap=""><!---->I have to because there was no DelegatingEObjectImpl available. Would it
be a good idea to add one now?

</pre>
<blockquote type="cite">
<pre wrap="">If we make progress on
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706">https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706</a> it's likely
you'll be increasing the lower bound for CDO...
</pre>
</blockquote>
<pre wrap=""><!---->I know ;-)

Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>


</pre>
<blockquote type="cite">
<pre wrap="">
Eike Stepper wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Joel,

I don't foresee a need to change the lower bound of our dependency
ranges, but we'll continue to develop and test against Platform 3.6 and
EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
I'm currently not 100% sure that CDO continues to function well with pre
M4 EMF, but I believe it ;-)

Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>



Joel Rosi-Schwartz schrieb:

</pre>
<blockquote type="cite">
<pre wrap="">Hi Eike,

What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
does have such a dependency, are you looking to keep CDO 3.0 clean of
these or do you suspect that you will have to pick them up before 3.0
is complete?

Thanks,
Joel
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>

--------------010801050307080406030008--
Re: CDO 3.0 dependency on Helios [message #504495 is a reply to message #504490] Sun, 20 December 2009 18:01 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> I'm not sure what a DelegatingEObjectImpl would be/do
It would implement InternalEObject by delegating all methods to
"InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
but if you add methods to InternalEObject we have to do it as well.

> nor why it couldn't extend BasicEObjectImpl.
BasicEObjectImpl has a lot of own logic that I just don't need. I need
more of a proxy/wrapper/delegating implementation.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
>
> Eike Stepper wrote:
>> Ed Merks schrieb:
>>
>>> Eike,
>>>
>>> Note that adding methods to EObject isn't breaking the API because
>>> EObject should not be implemented directly by clients.
>>>
>> I have to because there was no DelegatingEObjectImpl available. Would it
>> be a good idea to add one now?
>>
>>
>>> If we make progress on
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706 it's likely
>>> you'll be increasing the lower bound for CDO...
>>>
>> I know ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>> Eike Stepper wrote:
>>>
>>>> Hi Joel,
>>>>
>>>> I don't foresee a need to change the lower bound of our dependency
>>>> ranges, but we'll continue to develop and test against Platform 3.6 and
>>>> EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
>>>> I'm currently not 100% sure that CDO continues to function well with pre
>>>> M4 EMF, but I believe it ;-)
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>> Joel Rosi-Schwartz schrieb:
>>>>
>>>>
>>>>> Hi Eike,
>>>>>
>>>>> What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
>>>>> does have such a dependency, are you looking to keep CDO 3.0 clean of
>>>>> these or do you suspect that you will have to pick them up before 3.0
>>>>> is complete?
>>>>>
>>>>> Thanks,
>>>>> Joel
>>>>>
Re: CDO 3.0 dependency on Helios [message #504527 is a reply to message #504495] Sun, 20 December 2009 23:36 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070203090506000804030408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Comments below.


Eike Stepper wrote:
> Ed Merks schrieb:
>
>> Eike,
>>
>> I'm not sure what a DelegatingEObjectImpl would be/do
>>
> It would implement InternalEObject by delegating all methods to
> "InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
> but if you add methods to InternalEObject we have to do it as well.
>
Such an implementation would likely violate the don't override equals
and hashCode edict.
>
>> nor why it couldn't extend BasicEObjectImpl.
>>
> BasicEObjectImpl has a lot of own logic that I just don't need. I need
> more of a proxy/wrapper/delegating implementation.
>
But it doesn't declare any fields, so there are no storage implications
for reusing it.
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>> Eike Stepper wrote:
>>
>>> Ed Merks schrieb:
>>>
>>>
>>>> Eike,
>>>>
>>>> Note that adding methods to EObject isn't breaking the API because
>>>> EObject should not be implemented directly by clients.
>>>>
>>>>
>>> I have to because there was no DelegatingEObjectImpl available. Would it
>>> be a good idea to add one now?
>>>
>>>
>>>
>>>> If we make progress on
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706 it's likely
>>>> you'll be increasing the lower bound for CDO...
>>>>
>>>>
>>> I know ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>>
>>>> Eike Stepper wrote:
>>>>
>>>>
>>>>> Hi Joel,
>>>>>
>>>>> I don't foresee a need to change the lower bound of our dependency
>>>>> ranges, but we'll continue to develop and test against Platform 3.6 and
>>>>> EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
>>>>> I'm currently not 100% sure that CDO continues to function well with pre
>>>>> M4 EMF, but I believe it ;-)
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>>
>>>>> Joel Rosi-Schwartz schrieb:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Eike,
>>>>>>
>>>>>> What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
>>>>>> does have such a dependency, are you looking to keep CDO 3.0 clean of
>>>>>> these or do you suspect that you will have to pick them up before 3.0
>>>>>> is complete?
>>>>>>
>>>>>> Thanks,
>>>>>> Joel
>>>>>>
>>>>>>

--------------070203090506000804030408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!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">
Eike,<br>
<br>
Comments below.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:hgmacq$49b$2@build.eclipse.org" type="cite">
<pre wrap="">Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Eike,

I'm not sure what a DelegatingEObjectImpl would be/do
</pre>
</blockquote>
<pre wrap=""><!---->It would implement InternalEObject by delegating all methods to
"InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
but if you add methods to InternalEObject we have to do it as well.
</pre>
</blockquote>
Such an implementation would likely violate the don't override equals
and hashCode edict.<br>
<blockquote cite="mid:hgmacq$49b$2@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">nor why it couldn't extend BasicEObjectImpl.
</pre>
</blockquote>
<pre wrap=""><!---->BasicEObjectImpl has a lot of own logic that I just don't need. I need
more of a proxy/wrapper/delegating implementation.
</pre>
</blockquote>
But it doesn't declare any fields, so there are no storage implications
for reusing it.<br>
<blockquote cite="mid:hgmacq$49b$2@build.eclipse.org" type="cite">
<pre wrap="">
Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>


</pre>
<blockquote type="cite">
<pre wrap="">
Eike Stepper wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed Merks schrieb:

</pre>
<blockquote type="cite">
<pre wrap="">Eike,

Note that adding methods to EObject isn't breaking the API because
EObject should not be implemented directly by clients.

</pre>
</blockquote>
<pre wrap="">I have to because there was no DelegatingEObjectImpl available. Would it
be a good idea to add one now?


</pre>
<blockquote type="cite">
<pre wrap="">If we make progress on
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706">https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706</a> it's likely
you'll be increasing the lower bound for CDO...

</pre>
</blockquote>
<pre wrap="">I know ;-)

Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>



</pre>
<blockquote type="cite">
<pre wrap="">Eike Stepper wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hi Joel,

I don't foresee a need to change the lower bound of our dependency
ranges, but we'll continue to develop and test against Platform 3.6 and
EMF 2.6. As you might have realized, EMF broke the EObject API with M4.
I'm currently not 100% sure that CDO continues to function well with pre
M4 EMF, but I believe it ;-)

Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>



Joel Rosi-Schwartz schrieb:


</pre>
<blockquote type="cite">
<pre wrap="">Hi Eike,

What are CDO's plans in regards to Eclipse 3.6 dependency? EMF 2.6
does have such a dependency, are you looking to keep CDO 3.0 clean of
these or do you suspect that you will have to pick them up before 3.0
is complete?

Thanks,
Joel

</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>

--------------070203090506000804030408--
Re: CDO 3.0 dependency on Helios [message #504861 is a reply to message #504527] Wed, 23 December 2009 02:38 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
>> It would implement InternalEObject by delegating all methods to
>> "InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
>> but if you add methods to InternalEObject we have to do it as well.
>>
> Such an implementation would likely violate the don't override equals
> and hashCode edict.
Can you please explain what this edit means / implies? In CDO we have
such a DelegatingEObjectImpl for a long time already. It does not extend
any class but only implements a couple of interfaces, so there is no
equals and hashCode overridden.

>>
>>> nor why it couldn't extend BasicEObjectImpl.
>>>
>> BasicEObjectImpl has a lot of own logic that I just don't need. I need
>> more of a proxy/wrapper/delegating implementation.
>>
> But it doesn't declare any fields, so there are no storage
> implications for reusing it.
It's unlikely that new methods in InternalEObject end up in purely
delegating implementations in BasicEObjectImpl.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: CDO 3.0 dependency on Helios [message #504939 is a reply to message #504861] Wed, 23 December 2009 11:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040703030008060305030305
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Comments below.

Eike Stepper wrote:
>>> It would implement InternalEObject by delegating all methods to
>>> "InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
>>> but if you add methods to InternalEObject we have to do it as well.
>>>
>>>
>> Such an implementation would likely violate the don't override equals
>> and hashCode edict.
>>
> Can you please explain what this edit means / implies?
The implication being that we expect x.equals(y) == (x == y) for
anything that implements EObject.
> In CDO we have
> such a DelegatingEObjectImpl for a long time already.
One might expect a delegating implementation to delegate all methods,
including equals and hashCode...
> It does not extend
> any class but only implements a couple of interfaces, so there is no
> equals and hashCode overridden.
>
Is there a fundamental reason for not extending BasicEObjectImpl to
protect yourself against binary breakage?
>
>>>
>>>
>>>> nor why it couldn't extend BasicEObjectImpl.
>>>>
>>>>
>>> BasicEObjectImpl has a lot of own logic that I just don't need. I need
>>> more of a proxy/wrapper/delegating implementation.
>>>
>>>
>> But it doesn't declare any fields, so there are no storage
>> implications for reusing it.
>>
> It's unlikely that new methods in InternalEObject end up in purely
> delegating implementations in BasicEObjectImpl.
>
That's probably true, but is that a fundamental reason not to reuse the
base class that's been provided?
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>

--------------040703030008060305030305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!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">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:hgshea$v1e$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">It would implement InternalEObject by delegating all methods to
"InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
but if you add methods to InternalEObject we have to do it as well.

</pre>
</blockquote>
<pre wrap="">Such an implementation would likely violate the don't override equals
and hashCode edict.
</pre>
</blockquote>
<pre wrap=""><!---->Can you please explain what this edit means / implies? </pre>
</blockquote>
The implication being that we expect x.equals(y) == (x == y) for
anything that implements EObject.<br>
<blockquote cite="mid:hgshea$v1e$1@build.eclipse.org" type="cite">
<pre wrap="">In CDO we have
such a DelegatingEObjectImpl for a long time already.</pre>
</blockquote>
One might expect a delegating implementation to delegate all methods,
including equals and hashCode...<br>
<blockquote cite="mid:hgshea$v1e$1@build.eclipse.org" type="cite">
<pre wrap=""> It does not extend
any class but only implements a couple of interfaces, so there is no
equals and hashCode overridden.
</pre>
</blockquote>
Is there a fundamental reason for not extending BasicEObjectImpl to
protect yourself against binary breakage?<br>
<blockquote cite="mid:hgshea$v1e$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">nor why it couldn't extend BasicEObjectImpl.

</pre>
</blockquote>
<pre wrap="">BasicEObjectImpl has a lot of own logic that I just don't need. I need
more of a proxy/wrapper/delegating implementation.

</pre>
</blockquote>
<pre wrap="">But it doesn't declare any fields, so there are no storage
implications for reusing it.
</pre>
</blockquote>
<pre wrap=""><!---->It's unlikely that new methods in InternalEObject end up in purely
delegating implementations in BasicEObjectImpl.
</pre>
</blockquote>
That's probably true, but is that a fundamental reason not to reuse the
base class that's been provided?<br>
<blockquote cite="mid:hgshea$v1e$1@build.eclipse.org" type="cite">
<pre wrap="">
Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>

</pre>
</blockquote>
</body>
</html>

--------------040703030008060305030305--
Re: CDO 3.0 dependency on Helios [message #504953 is a reply to message #504939] Wed, 23 December 2009 08:40 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>>>> It would implement InternalEObject by delegating all methods to
>>>> "InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
>>>> but if you add methods to InternalEObject we have to do it as well.
>>>>
>>>>
>>> Such an implementation would likely violate the don't override equals
>>> and hashCode edict.
>>>
>> Can you please explain what this edit means / implies?
> The implication being that we expect x.equals(y) == (x == y) for
> anything that implements EObject.
Even if this object is not exposed to clients of the framework?

>> In CDO we have
>> such a DelegatingEObjectImpl for a long time already.
> One might expect a delegating implementation to delegate all methods,
> including equals and hashCode...
InternalEObject doesn't have these methods.

>> It does not extend
>> any class but only implements a couple of interfaces, so there is no
>> equals and hashCode overridden.
>>
> Is there a fundamental reason for not extending BasicEObjectImpl to
> protect yourself against binary breakage?
Yes, the method bodies of BasicEObjectImpl do not do what I want. They
do not simply delegate to another InternalEObject. As a consequence I
would have to override them all. No difference to what I have now :P

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>>
>>>>
>>>>
>>>>> nor why it couldn't extend BasicEObjectImpl.
>>>>>
>>>>>
>>>> BasicEObjectImpl has a lot of own logic that I just don't need. I need
>>>> more of a proxy/wrapper/delegating implementation.
>>>>
>>>>
>>> But it doesn't declare any fields, so there are no storage
>>> implications for reusing it.
>>>
>> It's unlikely that new methods in InternalEObject end up in purely
>> delegating implementations in BasicEObjectImpl.
>>
> That's probably true, but is that a fundamental reason not to reuse
> the base class that's been provided?
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
Re: CDO 3.0 dependency on Helios [message #504971 is a reply to message #504953] Wed, 23 December 2009 16:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020000070403060408040406
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Comments below.

Eike Stepper wrote:
> Ed Merks schrieb:
>
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>>
>>>>> It would implement InternalEObject by delegating all methods to
>>>>> "InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
>>>>> but if you add methods to InternalEObject we have to do it as well.
>>>>>
>>>>>
>>>>>
>>>> Such an implementation would likely violate the don't override equals
>>>> and hashCode edict.
>>>>
>>>>
>>> Can you please explain what this edit means / implies?
>>>
>> The implication being that we expect x.equals(y) == (x == y) for
>> anything that implements EObject.
>>
> Even if this object is not exposed to clients of the framework?
>
I'm just saying what the framework expects, so it's problematic for the
framework to provide things that aren't going to conform to the
expectations of the rest of the framework.
>
>>> In CDO we have
>>> such a DelegatingEObjectImpl for a long time already.
>>>
>> One might expect a delegating implementation to delegate all methods,
>> including equals and hashCode...
>>
> InternalEObject doesn't have these methods.
>
No, that's why I use the word "might."
>
>>> It does not extend
>>> any class but only implements a couple of interfaces, so there is no
>>> equals and hashCode overridden.
>>>
>>>
>> Is there a fundamental reason for not extending BasicEObjectImpl to
>> protect yourself against binary breakage?
>>
> Yes, the method bodies of BasicEObjectImpl do not do what I want. They
> do not simply delegate to another InternalEObject. As a consequence I
> would have to override them all. No difference to what I have now :P
>
I expect that all the methods for supporting eInvoke would work well for
all dynamic models but be totally broken otherwise. Anyway, I
understand why you might want a delegating implementation but I'm
reluctant to provide something that will not play nicely with the rest
of the framework...
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>> nor why it couldn't extend BasicEObjectImpl.
>>>>>>
>>>>>>
>>>>>>
>>>>> BasicEObjectImpl has a lot of own logic that I just don't need. I need
>>>>> more of a proxy/wrapper/delegating implementation.
>>>>>
>>>>>
>>>>>
>>>> But it doesn't declare any fields, so there are no storage
>>>> implications for reusing it.
>>>>
>>>>
>>> It's unlikely that new methods in InternalEObject end up in purely
>>> delegating implementations in BasicEObjectImpl.
>>>
>>>
>> That's probably true, but is that a fundamental reason not to reuse
>> the base class that's been provided?
>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>

--------------020000070403060408040406
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">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:hgtngq$v1e$3@build.eclipse.org" type="cite">
<pre wrap="">Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Eike,

Comments below.

Eike Stepper wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">It would implement InternalEObject by delegating all methods to
"InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
but if you add methods to InternalEObject we have to do it as well.


</pre>
</blockquote>
<pre wrap="">Such an implementation would likely violate the don't override equals
and hashCode edict.

</pre>
</blockquote>
<pre wrap="">Can you please explain what this edit means / implies?
</pre>
</blockquote>
<pre wrap="">The implication being that we expect x.equals(y) == (x == y) for
anything that implements EObject.
</pre>
</blockquote>
<pre wrap=""><!---->Even if this object is not exposed to clients of the framework?
</pre>
</blockquote>
I'm just saying what the framework expects, so it's problematic for the
framework to provide things that aren't going to conform to the
expectations of the rest of the framework.<br>
<blockquote cite="mid:hgtngq$v1e$3@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">In CDO we have
such a DelegatingEObjectImpl for a long time already.
</pre>
</blockquote>
<pre wrap="">One might expect a delegating implementation to delegate all methods,
including equals and hashCode...
</pre>
</blockquote>
<pre wrap=""><!---->InternalEObject doesn't have these methods.
</pre>
</blockquote>
No, that's why I use the word "might."<br>
<blockquote cite="mid:hgtngq$v1e$3@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> It does not extend
any class but only implements a couple of interfaces, so there is no
equals and hashCode overridden.

</pre>
</blockquote>
<pre wrap="">Is there a fundamental reason for not extending BasicEObjectImpl to
protect yourself against binary breakage?
</pre>
</blockquote>
<pre wrap=""><!---->Yes, the method bodies of BasicEObjectImpl do not do what I want. They
do not simply delegate to another InternalEObject. As a consequence I
would have to override them all. No difference to what I have now :P
</pre>
</blockquote>
I expect that all the methods for supporting eInvoke would work well
for all dynamic models but be totally broken otherwise.  Anyway, I
understand why you might want a delegating implementation but I'm
reluctant to provide something that will not play nicely with the rest
of the framework...<br>
<blockquote cite="mid:hgtngq$v1e$3@build.eclipse.org" type="cite">
<pre wrap="">
Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>



</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">

</pre>
<blockquote type="cite">
<pre wrap="">nor why it couldn't extend BasicEObjectImpl.


</pre>
</blockquote>
<pre wrap="">BasicEObjectImpl has a lot of own logic that I just don't need. I need
more of a proxy/wrapper/delegating implementation.


</pre>
</blockquote>
<pre wrap="">But it doesn't declare any fields, so there are no storage
implications for reusing it.

</pre>
</blockquote>
<pre wrap="">It's unlikely that new methods in InternalEObject end up in purely
delegating implementations in BasicEObjectImpl.

</pre>
</blockquote>
<pre wrap="">That's probably true, but is that a fundamental reason not to reuse
the base class that's been provided?
</pre>
<blockquote type="cite">
<pre wrap="">Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>


</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>

--------------020000070403060408040406--
Re: CDO 3.0 dependency on Helios [message #509349 is a reply to message #504971] Fri, 22 January 2010 03:18 Go to previous messageGo to next message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Hi Eike,
I saw this post from a month back. I am not sure what the conclusion is. Are there obstacles in using nightly builds of
CDO 3.0 with Eclipse 3.5/2.5?

gr. Martin

Ed Merks wrote:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>> Ed Merks schrieb:
>>
>>> Eike,
>>>
>>> Comments below.
>>>
>>> Eike Stepper wrote:
>>>
>>>>>> It would implement InternalEObject by delegating all methods to
>>>>>> "InternalEObject getDelegate()". We have that in CDO (CDOLegacyWrapper)
>>>>>> but if you add methods to InternalEObject we have to do it as well.
>>>>>>
>>>>>>
>>>>>>
>>>>> Such an implementation would likely violate the don't override equals
>>>>> and hashCode edict.
>>>>>
>>>>>
>>>> Can you please explain what this edit means / implies?
>>>>
>>> The implication being that we expect x.equals(y) == (x == y) for
>>> anything that implements EObject.
>>>
>> Even if this object is not exposed to clients of the framework?
>>
> I'm just saying what the framework expects, so it's problematic for the
> framework to provide things that aren't going to conform to the
> expectations of the rest of the framework.
>>
>>>> In CDO we have
>>>> such a DelegatingEObjectImpl for a long time already.
>>>>
>>> One might expect a delegating implementation to delegate all methods,
>>> including equals and hashCode...
>>>
>> InternalEObject doesn't have these methods.
>>
> No, that's why I use the word "might."
>>
>>>> It does not extend
>>>> any class but only implements a couple of interfaces, so there is no
>>>> equals and hashCode overridden.
>>>>
>>>>
>>> Is there a fundamental reason for not extending BasicEObjectImpl to
>>> protect yourself against binary breakage?
>>>
>> Yes, the method bodies of BasicEObjectImpl do not do what I want. They
>> do not simply delegate to another InternalEObject. As a consequence I
>> would have to override them all. No difference to what I have now :P
>>
> I expect that all the methods for supporting eInvoke would work well for
> all dynamic models but be totally broken otherwise. Anyway, I
> understand why you might want a delegating implementation but I'm
> reluctant to provide something that will not play nicely with the rest
> of the framework...
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> nor why it couldn't extend BasicEObjectImpl.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> BasicEObjectImpl has a lot of own logic that I just don't need. I need
>>>>>> more of a proxy/wrapper/delegating implementation.
>>>>>>
>>>>>>
>>>>>>
>>>>> But it doesn't declare any fields, so there are no storage
>>>>> implications for reusing it.
>>>>>
>>>>>
>>>> It's unlikely that new methods in InternalEObject end up in purely
>>>> delegating implementations in BasicEObjectImpl.
>>>>
>>>>
>>> That's probably true, but is that a fundamental reason not to reuse
>>> the base class that's been provided?
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: CDO 3.0 dependency on Helios [message #509353 is a reply to message #509349] Fri, 22 January 2010 03:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Martin Taal schrieb:
> Hi Eike,
> I saw this post from a month back. I am not sure what the conclusion
> is. Are there obstacles in using nightly builds of CDO 3.0 with
> Eclipse 3.5/2.5?
IIRC. it's more a build issue as opposed to a runtime issue. It's just
impossible to compile CDOM4+ against EMF M4- without some errors. But
these errors should not lead to runtime problems if deployed together.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> gr. Martin
>
> Ed Merks wrote:
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>>> Ed Merks schrieb:
>>>
>>>> Eike,
>>>>
>>>> Comments below.
>>>>
>>>> Eike Stepper wrote:
>>>>
>>>>>>> It would implement InternalEObject by delegating all methods to
>>>>>>> "InternalEObject getDelegate()". We have that in CDO
>>>>>>> (CDOLegacyWrapper)
>>>>>>> but if you add methods to InternalEObject we have to do it as well.
>>>>>>>
>>>>>> Such an implementation would likely violate the don't override
>>>>>> equals
>>>>>> and hashCode edict.
>>>>>>
>>>>> Can you please explain what this edit means / implies?
>>>> The implication being that we expect x.equals(y) == (x == y) for
>>>> anything that implements EObject.
>>>>
>>> Even if this object is not exposed to clients of the framework?
>>>
>> I'm just saying what the framework expects, so it's problematic for
>> the framework to provide things that aren't going to conform to the
>> expectations of the rest of the framework.
>>>
>>>>> In CDO we have
>>>>> such a DelegatingEObjectImpl for a long time already.
>>>>>
>>>> One might expect a delegating implementation to delegate all methods,
>>>> including equals and hashCode...
>>>>
>>> InternalEObject doesn't have these methods.
>>>
>> No, that's why I use the word "might."
>>>
>>>>> It does not extend
>>>>> any class but only implements a couple of interfaces, so there is no
>>>>> equals and hashCode overridden.
>>>>>
>>>> Is there a fundamental reason for not extending BasicEObjectImpl to
>>>> protect yourself against binary breakage?
>>>>
>>> Yes, the method bodies of BasicEObjectImpl do not do what I want. They
>>> do not simply delegate to another InternalEObject. As a consequence I
>>> would have to override them all. No difference to what I have now :P
>>>
>> I expect that all the methods for supporting eInvoke would work well
>> for all dynamic models but be totally broken otherwise. Anyway, I
>> understand why you might want a delegating implementation but I'm
>> reluctant to provide something that will not play nicely with the
>> rest of the framework...
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>>
>>>>>
>>>>>>>
>>>>>>>> nor why it couldn't extend BasicEObjectImpl.
>>>>>>>>
>>>>>>> BasicEObjectImpl has a lot of own logic that I just don't need.
>>>>>>> I need
>>>>>>> more of a proxy/wrapper/delegating implementation.
>>>>>>>
>>>>>> But it doesn't declare any fields, so there are no storage
>>>>>> implications for reusing it.
>>>>>>
>>>>> It's unlikely that new methods in InternalEObject end up in purely
>>>>> delegating implementations in BasicEObjectImpl.
>>>>>
>>>> That's probably true, but is that a fundamental reason not to reuse
>>>> the base class that's been provided?
>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>
>
Re: CDO 3.0 dependency on Helios [message #509455 is a reply to message #509353] Fri, 22 January 2010 03:46 Go to previous message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Okay, I tested the tutorials I wrote with Eclipse 3.5, EMF 2.5 and this worked, although this test is very limited (to
say the least)...

gr. Martin

Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> I saw this post from a month back. I am not sure what the conclusion
>> is. Are there obstacles in using nightly builds of CDO 3.0 with
>> Eclipse 3.5/2.5?
> IIRC. it's more a build issue as opposed to a runtime issue. It's just
> impossible to compile CDOM4+ against EMF M4- without some errors. But
> these errors should not lead to runtime problems if deployed together.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Eike,
>>>
>>> Comments below.
>>>
>>> Eike Stepper wrote:
>>>> Ed Merks schrieb:
>>>>
>>>>> Eike,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>
>>>>>>>> It would implement InternalEObject by delegating all methods to
>>>>>>>> "InternalEObject getDelegate()". We have that in CDO
>>>>>>>> (CDOLegacyWrapper)
>>>>>>>> but if you add methods to InternalEObject we have to do it as well.
>>>>>>>>
>>>>>>> Such an implementation would likely violate the don't override
>>>>>>> equals
>>>>>>> and hashCode edict.
>>>>>>>
>>>>>> Can you please explain what this edit means / implies?
>>>>> The implication being that we expect x.equals(y) == (x == y) for
>>>>> anything that implements EObject.
>>>>>
>>>> Even if this object is not exposed to clients of the framework?
>>>>
>>> I'm just saying what the framework expects, so it's problematic for
>>> the framework to provide things that aren't going to conform to the
>>> expectations of the rest of the framework.
>>>>
>>>>>> In CDO we have
>>>>>> such a DelegatingEObjectImpl for a long time already.
>>>>>>
>>>>> One might expect a delegating implementation to delegate all methods,
>>>>> including equals and hashCode...
>>>>>
>>>> InternalEObject doesn't have these methods.
>>>>
>>> No, that's why I use the word "might."
>>>>
>>>>>> It does not extend
>>>>>> any class but only implements a couple of interfaces, so there is no
>>>>>> equals and hashCode overridden.
>>>>>>
>>>>> Is there a fundamental reason for not extending BasicEObjectImpl to
>>>>> protect yourself against binary breakage?
>>>>>
>>>> Yes, the method bodies of BasicEObjectImpl do not do what I want. They
>>>> do not simply delegate to another InternalEObject. As a consequence I
>>>> would have to override them all. No difference to what I have now :P
>>>>
>>> I expect that all the methods for supporting eInvoke would work well
>>> for all dynamic models but be totally broken otherwise. Anyway, I
>>> understand why you might want a delegating implementation but I'm
>>> reluctant to provide something that will not play nicely with the
>>> rest of the framework...
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> nor why it couldn't extend BasicEObjectImpl.
>>>>>>>>>
>>>>>>>> BasicEObjectImpl has a lot of own logic that I just don't need.
>>>>>>>> I need
>>>>>>>> more of a proxy/wrapper/delegating implementation.
>>>>>>>>
>>>>>>> But it doesn't declare any fields, so there are no storage
>>>>>>> implications for reusing it.
>>>>>>>
>>>>>> It's unlikely that new methods in InternalEObject end up in purely
>>>>>> delegating implementations in BasicEObjectImpl.
>>>>>>
>>>>> That's probably true, but is that a fundamental reason not to reuse
>>>>> the base class that's been provided?
>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>> ----
>>>>>> http://thegordian.blogspot.com
>>>>>> http://twitter.com/eikestepper
>>>>>>
>>>>>>
>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Previous Topic:Defining the Java package in the ecore model
Next Topic:[CDO] Persisting cross-referenced models
Goto Forum:
  


Current Time: Thu Jul 31 09:31:16 EDT 2014

Powered by FUDForum. Page generated in 0.04154 seconds