Home » Modeling » EMF » CDO 3.0 dependency on Helios
| CDO 3.0 dependency on Helios [message #504462] |
Sat, 19 December 2009 17:41  |
|
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 06:14  |
|
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 #504490 is a reply to message #504483] |
Sun, 20 December 2009 10:32 |
 Ed Merks
Messages: 33137
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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: CDO 3.0 dependency on Helios [message #504495 is a reply to message #504490] |
Sun, 20 December 2009 23:01 |
|
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
>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO 3.0 dependency on Helios [message #504527 is a reply to message #504495] |
Mon, 21 December 2009 04:36 |
Ed Merks
Messages: 33137
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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: CDO 3.0 dependency on Helios [message #504861 is a reply to message #504527] |
Wed, 23 December 2009 07:38 |
|
>> 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
Cheers
/Eike
----
http://www.esc-net.de
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 16:22 |
Ed Merks
Messages: 33137
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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: CDO 3.0 dependency on Helios [message #504953 is a reply to message #504939] |
Wed, 23 December 2009 13:40 |
|
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
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
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 21:08 |
Ed Merks
Messages: 33137
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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: CDO 3.0 dependency on Helios [message #509349 is a reply to message #504971] |
Fri, 22 January 2010 08:18 |
Martin Taal
Messages: 5468
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 08:42 |
|
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
>>>>>
>>>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
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 08:46 |
Martin Taal
Messages: 5468
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
|
|
|
Goto Forum:
Current Time: Fri Apr 19 21:51:27 GMT 2024
Powered by FUDForum. Page generated in 0.04960 seconds |
] 
Search
Help
Register
Login
Home
