Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Delegates for creating instances of data types
Delegates for creating instances of data types [message #687091] Sun, 29 May 2011 15:18 Go to next message
Eclipse UserFriend
Originally posted by:

Hi,

I've been using EMF delegates for some time and they are great for
interactively enriching a model with Javascript or OCL. There is one
thing I miss, however, and that is the ability to create instances of an
EDataType. This should allow creating an instance from a String and
converting it back, using two expressions (or body statements) in
appropriate annotations. This kind of delegate should used by the
standard factory, so you have the choice of either adding the
annotations or generating and implementing the createXXXFromString and
convertXXToString.

If this makes sense, I can try to implement it and submit the code for
review by the EMF team.

Hallvard
Re: Delegates for creating instances of data types [message #687092 is a reply to message #687091] Sun, 29 May 2011 15:56 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Hallvard

Do you mean that you want to be able to program the body of e.g.
convertXXToString in the Ecore model?

FromString is specific to EDataType which cannot have a special
operation so I guess it just needs to be an agreed EAnnotation.

ToString is more general; you might allow customisation of toString for
all EClassifiers, but again I guess it just needs to be an agreed
EAnnotation.

You need to check the UML2Ecore conversion carefully because there is a
surprising amount of generation capability for UML and you might find
that what you want is already more than 90% implemented.

Regards

Ed Willink


On 29/05/2011 16:18, Hallvard Trætteberg wrote:
> Hi,
>
> I've been using EMF delegates for some time and they are great for
> interactively enriching a model with Javascript or OCL. There is one
> thing I miss, however, and that is the ability to create instances of
> an EDataType. This should allow creating an instance from a String and
> converting it back, using two expressions (or body statements) in
> appropriate annotations. This kind of delegate should used by the
> standard factory, so you have the choice of either adding the
> annotations or generating and implementing the createXXXFromString and
> convertXXToString.
>
> If this makes sense, I can try to implement it and submit the code for
> review by the EMF team.
>
> Hallvard
Re: Delegates for creating instances of data types [message #687093 is a reply to message #687092] Sun, 29 May 2011 20:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 29.05.11 17.56, Ed Willink wrote:
>
> Do you mean that you want to be able to program the body of e.g.
> convertXXToString in the Ecore model?
>
> FromString is specific to EDataType which cannot have a special
> operation so I guess it just needs to be an agreed EAnnotation.
>
> ToString is more general; you might allow customisation of toString for
> all EClassifiers, but again I guess it just needs to be an agreed
> EAnnotation.

Yes, the idea is to define two annotations for an EDataType, one for the
body of convertXXXToString and one for the body of createXXXFromString
(similar to the annotation for an EOperation body). Then you can use
your favorite scripting language (currently OCL and very soon
Javascript) to support custom EDataTypes without generating the factory
code and implementing it in Java.

> You need to check the UML2Ecore conversion carefully because there is a
> surprising amount of generation capability for UML and you might find
> that what you want is already more than 90% implemented.

I'm not using UML, hence I want Ecore to support it directly.

Hallvard
Re: Delegates for creating instances of data types [message #687094 is a reply to message #687093] Mon, 30 May 2011 01:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Hallvard,

It does make sense. Ideally we'd have something that even works for
dynamic models. Of course there is already reflective support that
looks for a String constructor (or valueOf method) and calls toString,
but if it's a class over which you have no control, that doesn't really
help.


Hallvard Trætteberg wrote:
> On 29.05.11 17.56, Ed Willink wrote:
>>
>> Do you mean that you want to be able to program the body of e.g.
>> convertXXToString in the Ecore model?
>>
>> FromString is specific to EDataType which cannot have a special
>> operation so I guess it just needs to be an agreed EAnnotation.
>>
>> ToString is more general; you might allow customisation of toString for
>> all EClassifiers, but again I guess it just needs to be an agreed
>> EAnnotation.
>
> Yes, the idea is to define two annotations for an EDataType, one for
> the body of convertXXXToString and one for the body of
> createXXXFromString (similar to the annotation for an EOperation
> body). Then you can use your favorite scripting language (currently
> OCL and very soon Javascript) to support custom EDataTypes without
> generating the factory code and implementing it in Java.
>
>> You need to check the UML2Ecore conversion carefully because there is a
>> surprising amount of generation capability for UML and you might find
>> that what you want is already more than 90% implemented.
>
> I'm not using UML, hence I want Ecore to support it directly.
>
> Hallvard


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Delegates for creating instances of data types [message #687095 is a reply to message #687093] Mon, 30 May 2011 07:09 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Hallvard
>> You need to check the UML2Ecore conversion carefully because there is a
>> surprising amount of generation capability for UML and you might find
>> that what you want is already more than 90% implemented.
>
> I'm not using UML, hence I want Ecore to support it directly.
>
I'm not suggesting that you use UML, just understand the EAnnotations
that UML2Ecore already uses so that you avoid another duplication
similar to that by the EMF invocation delegate annotation of the
GenModel operation body annotation.

I'm planning to get direct OCL to Java generation going in an
intermediate OCL 3.2 release. This will cut out the parsing overheads
and much of the run-time dispatch overheads by directly calling the OCL
library operations. This needs integration with genmodel. Perhaps it is
similar to something you need.

I perhaps misunderstood a comment at the Eclipse Summit that IIRC EEF
are migrating EMF's JET scripts to M2M. If so, it would be good to try
to exploit this so that the added-value EAnnotation functionality was in
identifiable modules rather than woven into obscure places.

Regards

Ed
Re: Delegates for creating instances of data types [message #687096 is a reply to message #687095] Mon, 30 May 2011 08:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 30.05.11 09.09, Ed Willink wrote:
>
> I'm not suggesting that you use UML, just understand the EAnnotations
> that UML2Ecore already uses so that you avoid another duplication
> similar to that by the EMF invocation delegate annotation of the
> GenModel operation body annotation.

You mean we should reuse an eAnnotation source and key pair if this is
already somehow supported by UML2Ecore, to avoid getting yet another
pair. Perhaps someone with knowledge about this can tell us if this is
the case?

> I'm planning to get direct OCL to Java generation going in an
> intermediate OCL 3.2 release. This will cut out the parsing overheads
> and much of the run-time dispatch overheads by directly calling the OCL
> library operations. This needs integration with genmodel. Perhaps it is
> similar to something you need.

Not at this point, but could be in the future.

Hallvard
Re: Delegates for creating instances of data types [message #687097 is a reply to message #687094] Mon, 30 May 2011 09:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 30.05.11 03.21, Ed Merks wrote:
>
> It does make sense. Ideally we'd have something that even works for
> dynamic models. Of course there is already reflective support that looks
> for a String constructor (or valueOf method) and calls toString, but if
> it's a class over which you have no control, that doesn't really help.

E.g. java.net.URI has a static create method.

I have create this bugzilla and attached to it an experimental
implementation that works with js4emf:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347611

Hallvard
Re: Delegates for creating instances of data types [message #687098 is a reply to message #687096] Mon, 30 May 2011 09:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Hallvard
>>
>> I'm not suggesting that you use UML, just understand the EAnnotations
>> that UML2Ecore already uses so that you avoid another duplication
>> similar to that by the EMF invocation delegate annotation of the
>> GenModel operation body annotation.
>
> You mean we should reuse an eAnnotation source and key pair if this is
> already somehow supported by UML2Ecore, to avoid getting yet another
> pair. Perhaps someone with knowledge about this can tell us if this is
> the case?
Most, perhaps all, of the Ecore annotations are described in the EMF
book, but the EMF delegates are not and the UML annotations are not.

I think someone, ?? you ??, would be doing a great service by greping
all *.jet* files in EMF and UML2 for anything that looks like an
EAnnotation source, and then creating a wiki page mapping source URI to
genmodel functionality. We could then retrofit reference documentation
and API contracts on what each EAnnotation source URI means, rather than
rely on examples of how to solve XSD and UML problems.

Regards

Ed Willink
Re: Delegates for creating instances of data types [message #687101 is a reply to message #687097] Mon, 30 May 2011 15:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Hallvard,

We could add reflective support for more common patterns; it doesn't
seem likely thought that we could cover them all.


Hallvard Trætteberg wrote:
> On 30.05.11 03.21, Ed Merks wrote:
>>
>> It does make sense. Ideally we'd have something that even works for
>> dynamic models. Of course there is already reflective support that looks
>> for a String constructor (or valueOf method) and calls toString, but if
>> it's a class over which you have no control, that doesn't really help.
>
> E.g. java.net.URI has a static create method.
>
> I have create this bugzilla and attached to it an experimental
> implementation that works with js4emf:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=347611
>
> Hallvard


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Delegates for creating instances of data types [message #687102 is a reply to message #687101] Mon, 30 May 2011 15:25 Go to previous message
Eclipse UserFriend
Originally posted by:

On 30.05.11 17.06, Ed Merks wrote:
>
> We could add reflective support for more common patterns; it doesn't
> seem likely thought that we could cover them all.

In many cases, there isn't an natural/obvious text format, so you'll
have to invent one for the sake of the model. That's why a pluggable
delegate makes sense. I hope someone has time to look at the attachment.
I could take it further, e.g. make a complete patch, but I would like an
evaluation of the current suggestion first.

>> I have create this bugzilla and attached to it an experimental
>> implementation that works with js4emf:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=347611

Hallvard
Re: Delegates for creating instances of data types [message #687309 is a reply to message #687091] Sun, 29 May 2011 15:56 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Hallvard

Do you mean that you want to be able to program the body of e.g.
convertXXToString in the Ecore model?

FromString is specific to EDataType which cannot have a special
operation so I guess it just needs to be an agreed EAnnotation.

ToString is more general; you might allow customisation of toString for
all EClassifiers, but again I guess it just needs to be an agreed
EAnnotation.

You need to check the UML2Ecore conversion carefully because there is a
surprising amount of generation capability for UML and you might find
that what you want is already more than 90% implemented.

Regards

Ed Willink


On 29/05/2011 16:18, Hallvard Trætteberg wrote:
> Hi,
>
> I've been using EMF delegates for some time and they are great for
> interactively enriching a model with Javascript or OCL. There is one
> thing I miss, however, and that is the ability to create instances of
> an EDataType. This should allow creating an instance from a String and
> converting it back, using two expressions (or body statements) in
> appropriate annotations. This kind of delegate should used by the
> standard factory, so you have the choice of either adding the
> annotations or generating and implementing the createXXXFromString and
> convertXXToString.
>
> If this makes sense, I can try to implement it and submit the code for
> review by the EMF team.
>
> Hallvard
Re: Delegates for creating instances of data types [message #687311 is a reply to message #687092] Sun, 29 May 2011 20:46 Go to previous message
Eclipse UserFriend
Originally posted by:

On 29.05.11 17.56, Ed Willink wrote:
>
> Do you mean that you want to be able to program the body of e.g.
> convertXXToString in the Ecore model?
>
> FromString is specific to EDataType which cannot have a special
> operation so I guess it just needs to be an agreed EAnnotation.
>
> ToString is more general; you might allow customisation of toString for
> all EClassifiers, but again I guess it just needs to be an agreed
> EAnnotation.

Yes, the idea is to define two annotations for an EDataType, one for the
body of convertXXXToString and one for the body of createXXXFromString
(similar to the annotation for an EOperation body). Then you can use
your favorite scripting language (currently OCL and very soon
Javascript) to support custom EDataTypes without generating the factory
code and implementing it in Java.

> You need to check the UML2Ecore conversion carefully because there is a
> surprising amount of generation capability for UML and you might find
> that what you want is already more than 90% implemented.

I'm not using UML, hence I want Ecore to support it directly.

Hallvard
Re: Delegates for creating instances of data types [message #687312 is a reply to message #687093] Mon, 30 May 2011 01:21 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Hallvard,

It does make sense. Ideally we'd have something that even works for
dynamic models. Of course there is already reflective support that
looks for a String constructor (or valueOf method) and calls toString,
but if it's a class over which you have no control, that doesn't really
help.


Hallvard Trætteberg wrote:
> On 29.05.11 17.56, Ed Willink wrote:
>>
>> Do you mean that you want to be able to program the body of e.g.
>> convertXXToString in the Ecore model?
>>
>> FromString is specific to EDataType which cannot have a special
>> operation so I guess it just needs to be an agreed EAnnotation.
>>
>> ToString is more general; you might allow customisation of toString for
>> all EClassifiers, but again I guess it just needs to be an agreed
>> EAnnotation.
>
> Yes, the idea is to define two annotations for an EDataType, one for
> the body of convertXXXToString and one for the body of
> createXXXFromString (similar to the annotation for an EOperation
> body). Then you can use your favorite scripting language (currently
> OCL and very soon Javascript) to support custom EDataTypes without
> generating the factory code and implementing it in Java.
>
>> You need to check the UML2Ecore conversion carefully because there is a
>> surprising amount of generation capability for UML and you might find
>> that what you want is already more than 90% implemented.
>
> I'm not using UML, hence I want Ecore to support it directly.
>
> Hallvard


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Delegates for creating instances of data types [message #687315 is a reply to message #687093] Mon, 30 May 2011 07:09 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Hallvard
>> You need to check the UML2Ecore conversion carefully because there is a
>> surprising amount of generation capability for UML and you might find
>> that what you want is already more than 90% implemented.
>
> I'm not using UML, hence I want Ecore to support it directly.
>
I'm not suggesting that you use UML, just understand the EAnnotations
that UML2Ecore already uses so that you avoid another duplication
similar to that by the EMF invocation delegate annotation of the
GenModel operation body annotation.

I'm planning to get direct OCL to Java generation going in an
intermediate OCL 3.2 release. This will cut out the parsing overheads
and much of the run-time dispatch overheads by directly calling the OCL
library operations. This needs integration with genmodel. Perhaps it is
similar to something you need.

I perhaps misunderstood a comment at the Eclipse Summit that IIRC EEF
are migrating EMF's JET scripts to M2M. If so, it would be good to try
to exploit this so that the added-value EAnnotation functionality was in
identifiable modules rather than woven into obscure places.

Regards

Ed
Re: Delegates for creating instances of data types [message #687319 is a reply to message #687095] Mon, 30 May 2011 08:51 Go to previous message
Eclipse UserFriend
Originally posted by:

On 30.05.11 09.09, Ed Willink wrote:
>
> I'm not suggesting that you use UML, just understand the EAnnotations
> that UML2Ecore already uses so that you avoid another duplication
> similar to that by the EMF invocation delegate annotation of the
> GenModel operation body annotation.

You mean we should reuse an eAnnotation source and key pair if this is
already somehow supported by UML2Ecore, to avoid getting yet another
pair. Perhaps someone with knowledge about this can tell us if this is
the case?

> I'm planning to get direct OCL to Java generation going in an
> intermediate OCL 3.2 release. This will cut out the parsing overheads
> and much of the run-time dispatch overheads by directly calling the OCL
> library operations. This needs integration with genmodel. Perhaps it is
> similar to something you need.

Not at this point, but could be in the future.

Hallvard
Re: Delegates for creating instances of data types [message #687320 is a reply to message #687094] Mon, 30 May 2011 09:12 Go to previous message
Eclipse UserFriend
Originally posted by:

On 30.05.11 03.21, Ed Merks wrote:
>
> It does make sense. Ideally we'd have something that even works for
> dynamic models. Of course there is already reflective support that looks
> for a String constructor (or valueOf method) and calls toString, but if
> it's a class over which you have no control, that doesn't really help.

E.g. java.net.URI has a static create method.

I have create this bugzilla and attached to it an experimental
implementation that works with js4emf:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347611

Hallvard
Re: Delegates for creating instances of data types [message #687321 is a reply to message #687096] Mon, 30 May 2011 09:37 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Hallvard
>>
>> I'm not suggesting that you use UML, just understand the EAnnotations
>> that UML2Ecore already uses so that you avoid another duplication
>> similar to that by the EMF invocation delegate annotation of the
>> GenModel operation body annotation.
>
> You mean we should reuse an eAnnotation source and key pair if this is
> already somehow supported by UML2Ecore, to avoid getting yet another
> pair. Perhaps someone with knowledge about this can tell us if this is
> the case?
Most, perhaps all, of the Ecore annotations are described in the EMF
book, but the EMF delegates are not and the UML annotations are not.

I think someone, ?? you ??, would be doing a great service by greping
all *.jet* files in EMF and UML2 for anything that looks like an
EAnnotation source, and then creating a wiki page mapping source URI to
genmodel functionality. We could then retrofit reference documentation
and API contracts on what each EAnnotation source URI means, rather than
rely on examples of how to solve XSD and UML problems.

Regards

Ed Willink
Re: Delegates for creating instances of data types [message #687326 is a reply to message #687097] Mon, 30 May 2011 15:06 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Hallvard,

We could add reflective support for more common patterns; it doesn't
seem likely thought that we could cover them all.


Hallvard Trætteberg wrote:
> On 30.05.11 03.21, Ed Merks wrote:
>>
>> It does make sense. Ideally we'd have something that even works for
>> dynamic models. Of course there is already reflective support that looks
>> for a String constructor (or valueOf method) and calls toString, but if
>> it's a class over which you have no control, that doesn't really help.
>
> E.g. java.net.URI has a static create method.
>
> I have create this bugzilla and attached to it an experimental
> implementation that works with js4emf:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=347611
>
> Hallvard


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Delegates for creating instances of data types [message #687327 is a reply to message #687101] Mon, 30 May 2011 15:25 Go to previous message
Eclipse UserFriend
Originally posted by:

On 30.05.11 17.06, Ed Merks wrote:
>
> We could add reflective support for more common patterns; it doesn't
> seem likely thought that we could cover them all.

In many cases, there isn't an natural/obvious text format, so you'll
have to invent one for the sake of the model. That's why a pluggable
delegate makes sense. I hope someone has time to look at the attachment.
I could take it further, e.g. make a complete patch, but I would like an
evaluation of the current suggestion first.

>> I have create this bugzilla and attached to it an experimental
>> implementation that works with js4emf:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=347611

Hallvard
Previous Topic:(no subject)
Next Topic:Ant Problem
Goto Forum:
  


Current Time: Fri Mar 29 08:08:47 GMT 2024

Powered by FUDForum. Page generated in 0.04298 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top