|
| Re: [EMF & CDO] Re-implementing EObject classes in Scala as traits/mixins [message #1069524 is a reply to message #1069401] |
Tue, 16 July 2013 03:48   |
 Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Shahim,
Note this Javadoc on EObject:
Any EObject is assumed to also implement InternalEObject, which provides
lower-level access that is not necessarily suitable for general
consumption but is required for maintaining the EMF support mechanisms.
Implementations of EObject should extend BasicEObjectImpl or one of its
derived classes because methods can and will be added to this API. The
framework also assumes that implementations will not specialize
equals(Object) (nor hashCode()) so that "==" can be always used for
equality testing; EcoreUtil.equals should be used for doing structural
equality testing.
As such, while you could implement these interfaces directly, you'd
essentially need to replicate everything you see in EObjectImpl or
MinimalEObjectImpl, including their base class BasicObjectImpl and its
base class BasicNotifierImpl. The rest of the framework doesn't assume
you use these base classes, so that should be okay.
Eike can say more about what CDO assumes and expects...
On 15/07/2013 10:32 PM, Shahim Essaid wrote:
> Dear EMF/CDO experts,
>
> I have been thinking about prototyping the implementation of EObject
> in Scala as mixin traits so they can be mixed with any Java class to
> add an EMF aspect to them.
>
> I have a very basic question that might prevent me from pursuing this
> as mixins. Do the EMF and CDO runtimes depend in any way on the
> implementation classes of EObject or CDOObject? For example, if I
> generate Scala code for my EMF model that mixes in my Scala
> EObject/CDOObject trait (that takes care of all the implementation of
> the interfaces), can I then pass this object to the existing EMF/CDO
> APIs without problems?
>
> I will need to discuss more details later if I pursue this approach
> but the main question is whether or not I have to extend existing
> EMF/CDO classes (not interfaces) in any generated Scala code in order
> to inter-operate with the EMF/CDO runtime.
>
> Thanks,
> Shahim
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF & CDO] Re-implementing EObject classes in Scala as traits/mixins [message #1069606 is a reply to message #1069401] |
Tue, 16 July 2013 08:28 |
|
Am 15.07.2013 22:32, schrieb Shahim Essaid:
> Dear EMF/CDO experts,
>
> I have been thinking about prototyping the implementation of EObject in Scala as mixin traits so they can be mixed
> with any Java class to add an EMF aspect to them.
>
> I have a very basic question that might prevent me from pursuing this as mixins. Do the EMF and CDO runtimes depend in
> any way on the implementation classes of EObject or CDOObject? For example, if I generate Scala code for my EMF model
> that mixes in my Scala EObject/CDOObject trait (that takes care of all the implementation of the interfaces), can I
> then pass this object to the existing EMF/CDO APIs without problems?
>
> I will need to discuss more details later if I pursue this approach but the main question is whether or not I have to
> extend existing EMF/CDO classes (not interfaces) in any generated Scala code in order to inter-operate with the
> EMF/CDO runtime.
Similar to Ed's answer the CDO runtime only expects a CDOObject to implement InternalCDOObject.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.04569 seconds
] 
Search
Help
Register
Login
Home
