Home » Modeling » EMF » Deriving EMF from code: how to delay resolving types?
| |
| Re: Deriving EMF from code: how to delay resolving types? [message #380289 is a reply to message #380287] |
Tue, 11 November 2003 18:56   |
 Henrich Kraemer
Messages: 59
Registered: July 2009 |
Member |
|
|
It isn’t clear to me whether your suggestion address issue 1, does it?
It seems one can compute parts from URI from the parent or broader
context of the proxy supplier. If the meta-model captures the original
text (identifier) one could actually compute all parts of the URI. In
this case it seems it would be sufficient to just store “?” in the URI.
This would delay even more computation and keep the memory requirements
even lower.
Is this a feasible trade-off?
Ed Merks wrote:
> Henrich,
>
> This is a very interesting question. Clearly you need to encode enough
> information in the proxy URI that a reference can be resolved at a later
> point in time. One approach would be to encode something like this:
>
> <uri-of-point-of-reference>#?<identifier>@<fragment-of-point-of-reference >
>
> You would encode the resource containing the identifier reference, the
> identifier that will need to be resolved, and the specific object
> representing the location in the resource at which you want to resolve the
> identifier.
>
> In your specialized resource, you could override getEObject to recognize the
> above special syntax, i.e., fragments starting with "?". You'd use the
> fragment portion after the "@" to find the object in the resource, and then
> you'd resolve the identifier relative to that object to yield your final
> result, which can of course be an object in a different resource.
>
>
> Henrich Kraemer wrote:
>
>
>>Consider one wants to add support for a programming language in eclipse
>>similar to the JDT/CDT. One option would be to use EMF to represent the
>>code.
>>The primary form of code is text files and thus the EMF is derived from
>>the code. As an example consider a file containing among other stuff
>>the following text.
>>...
>>class A: public Stack {
>>...
>>
>>When the tool needs to visualize or manipulate the code it instantiates
>>an EMF model corresponding to the program text. Let’s assume that each
>>file becomes an EMF resource. This would mean that the EMF code model’s
>>implementation would provide its own ResourceImpl which will parse the
>>code and create the appropriate EMF objects.
>>
>>Say the EMF code model would represent a class as CodeClass. Therefore
>>the resource would contain an instance of CodeClass named ‘A’. CodeClass
>>contains an EReference with multiplicity 0..1 called base which points
>>to CodeClass.
>>
>>During loading of the EMF resource the reference will and should be
>>lazily resolved and therefore a proxy should be created.
>>
>>I believe the default EMF mechanism assumes that one knows the following
>>when a proxy is created:
>>1. What meta-type the supplier is going to be. The proxy-object is of
>>that supertype.
>>2. Which resource the supplier is going to be in.
>>3. Where exactly in the resource the proxy is at.
>>2 and 3 are stored as an URI in eProxiURI with the format of
>>“resource#fragment” on the proxy object.
>>
>>In contrast to the links found in EMF-XML documents all these questions
>>cannot be easily answered for code. It requires to actually locate the
>>Stack given imports project references etc. This is an expensive
>>operation that should be delayed to EReference resolution time.
>>
>>How can this be achieved?
>
>
|
|
|
| Re: Deriving EMF from code: how to delay resolving types? [message #380290 is a reply to message #380289] |
Tue, 11 November 2003 19:19 |
Henrich Kraemer
Messages: 59
Registered: July 2009 |
Member |
|
|
I just realized that only a string is passed into Resource.getEObject. I
think for the described scenario the approach to recompute all the
information would be superior in both space and time. However one would
need a hook into resolution where the proxy object is passed so that one
wouldn't have to find it first.
Is there a way to achieve this?
If there isn't a hook yet in EMF perhaps EMF could be extended to
support this of resolution which is context driven and has to be
provided entirely by the model implementer. Does this make sense to you?
Of course issue 1 should be addressed as well....
Henrich Kraemer wrote:
> It isn’t clear to me whether your suggestion address issue 1, does it?
>
> It seems one can compute parts from URI from the parent or broader
> context of the proxy supplier. If the meta-model captures the original
> text (identifier) one could actually compute all parts of the URI. In
> this case it seems it would be sufficient to just store “?” in the URI.
> This would delay even more computation and keep the memory requirements
> even lower.
> Is this a feasible trade-off?
>
>
> Ed Merks wrote:
>
>> Henrich,
>>
>> This is a very interesting question. Clearly you need to encode enough
>> information in the proxy URI that a reference can be resolved at a later
>> point in time. One approach would be to encode something like this:
>>
>>
>> <uri-of-point-of-reference>#?<identifier>@<fragment-of-point-of-reference >
>>
>>
>> You would encode the resource containing the identifier reference, the
>> identifier that will need to be resolved, and the specific object
>> representing the location in the resource at which you want to resolve
>> the
>> identifier.
>>
>> In your specialized resource, you could override getEObject to
>> recognize the
>> above special syntax, i.e., fragments starting with "?". You'd use the
>> fragment portion after the "@" to find the object in the resource, and
>> then
>> you'd resolve the identifier relative to that object to yield your final
>> result, which can of course be an object in a different resource.
>>
>>
>> Henrich Kraemer wrote:
>>
>>
>>> Consider one wants to add support for a programming language in eclipse
>>> similar to the JDT/CDT. One option would be to use EMF to represent the
>>> code.
>>> The primary form of code is text files and thus the EMF is derived from
>>> the code. As an example consider a file containing among other stuff
>>> the following text.
>>> ...
>>> class A: public Stack {
>>> ...
>>>
>>> When the tool needs to visualize or manipulate the code it instantiates
>>> an EMF model corresponding to the program text. Let’s assume that each
>>> file becomes an EMF resource. This would mean that the EMF code model’s
>>> implementation would provide its own ResourceImpl which will parse the
>>> code and create the appropriate EMF objects.
>>>
>>> Say the EMF code model would represent a class as CodeClass. Therefore
>>> the resource would contain an instance of CodeClass named ‘A’. CodeClass
>>> contains an EReference with multiplicity 0..1 called base which points
>>> to CodeClass.
>>>
>>> During loading of the EMF resource the reference will and should be
>>> lazily resolved and therefore a proxy should be created.
>>>
>>> I believe the default EMF mechanism assumes that one knows the following
>>> when a proxy is created:
>>> 1. What meta-type the supplier is going to be. The proxy-object is of
>>> that supertype.
>>> 2. Which resource the supplier is going to be in.
>>> 3. Where exactly in the resource the proxy is at.
>>> 2 and 3 are stored as an URI in eProxiURI with the format of
>>> “resource#fragment” on the proxy object.
>>>
>>> In contrast to the links found in EMF-XML documents all these questions
>>> cannot be easily answered for code. It requires to actually locate the
>>> Stack given imports project references etc. This is an expensive
>>> operation that should be delayed to EReference resolution time.
>>>
>>> How can this be achieved?
>>
>>
>>
>
|
|
|
| Re: Deriving EMF from code: how to delay resolving types? [message #380293 is a reply to message #380290] |
Wed, 12 November 2003 11:21 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Henrich,
It would be interesting if InternalEObject had an eResolve method that took a
proxy EObject as an argument. The code that calls EcoreUtil.resolve now would
call this method directly and the default implementation of it would just call
EcoreUtil.resolve, but a derived implementation could get fancy, i.e., you could
just encode the identifier. This would require changing the templates and some
of the built-in list implementations to use this new mechanism, but it all seems
pretty straight forward, has very little cost, and provides significant new
flexibility and potential performance improvements. I'll discuss this with the
team...
I didn't really understand your issue 1. A proxy EObject has to be of the right
type to be able to add/set it to the feature that it needs to live in. You do
not need to know the ultimate derived type of the object to which it will
resolve. Since you know the feature you are putting the proxy into (I guess),
you have all the type information you need. If I still haven't answered the
question, could you please rephrase it?
Henrich Kraemer wrote:
> I just realized that only a string is passed into Resource.getEObject. I
> think for the described scenario the approach to recompute all the
> information would be superior in both space and time. However one would
> need a hook into resolution where the proxy object is passed so that one
> wouldn't have to find it first.
> Is there a way to achieve this?
> If there isn't a hook yet in EMF perhaps EMF could be extended to
> support this of resolution which is context driven and has to be
> provided entirely by the model implementer. Does this make sense to you?
>
> Of course issue 1 should be addressed as well....
>
> Henrich Kraemer wrote:
>
> > It isnt clear to me whether your suggestion address issue 1, does it?
> >
> > It seems one can compute parts from URI from the parent or broader
> > context of the proxy supplier. If the meta-model captures the original
> > text (identifier) one could actually compute all parts of the URI. In
> > this case it seems it would be sufficient to just store ? in the URI.
> > This would delay even more computation and keep the memory requirements
> > even lower.
> > Is this a feasible trade-off?
> >
> >
> > Ed Merks wrote:
> >
> >> Henrich,
> >>
> >> This is a very interesting question. Clearly you need to encode enough
> >> information in the proxy URI that a reference can be resolved at a later
> >> point in time. One approach would be to encode something like this:
> >>
> >>
> >> <uri-of-point-of-reference>#?<identifier>@<fragment-of-point-of-reference >
> >>
> >>
> >> You would encode the resource containing the identifier reference, the
> >> identifier that will need to be resolved, and the specific object
> >> representing the location in the resource at which you want to resolve
> >> the
> >> identifier.
> >>
> >> In your specialized resource, you could override getEObject to
> >> recognize the
> >> above special syntax, i.e., fragments starting with "?". You'd use the
> >> fragment portion after the "@" to find the object in the resource, and
> >> then
> >> you'd resolve the identifier relative to that object to yield your final
> >> result, which can of course be an object in a different resource.
> >>
> >>
> >> Henrich Kraemer wrote:
> >>
> >>
> >>> Consider one wants to add support for a programming language in eclipse
> >>> similar to the JDT/CDT. One option would be to use EMF to represent the
> >>> code.
> >>> The primary form of code is text files and thus the EMF is derived from
> >>> the code. As an example consider a file containing among other stuff
> >>> the following text.
> >>> ...
> >>> class A: public Stack {
> >>> ...
> >>>
> >>> When the tool needs to visualize or manipulate the code it instantiates
> >>> an EMF model corresponding to the program text. Lets assume that each
> >>> file becomes an EMF resource. This would mean that the EMF code models
> >>> implementation would provide its own ResourceImpl which will parse the
> >>> code and create the appropriate EMF objects.
> >>>
> >>> Say the EMF code model would represent a class as CodeClass. Therefore
> >>> the resource would contain an instance of CodeClass named A. CodeClass
> >>> contains an EReference with multiplicity 0..1 called base which points
> >>> to CodeClass.
> >>>
> >>> During loading of the EMF resource the reference will and should be
> >>> lazily resolved and therefore a proxy should be created.
> >>>
> >>> I believe the default EMF mechanism assumes that one knows the following
> >>> when a proxy is created:
> >>> 1. What meta-type the supplier is going to be. The proxy-object is of
> >>> that supertype.
> >>> 2. Which resource the supplier is going to be in.
> >>> 3. Where exactly in the resource the proxy is at.
> >>> 2 and 3 are stored as an URI in eProxiURI with the format of
> >>> resource#fragment on the proxy object.
> >>>
> >>> In contrast to the links found in EMF-XML documents all these questions
> >>> cannot be easily answered for code. It requires to actually locate the
> >>> Stack given imports project references etc. This is an expensive
> >>> operation that should be delayed to EReference resolution time.
> >>>
> >>> How can this be achieved?
> >>
> >>
> >>
> >
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Deriving EMF from code: how to delay resolving types? [message #380527 is a reply to message #380293] |
Wed, 12 November 2003 22:31 |
Henrich Kraemer
Messages: 59
Registered: July 2009 |
Member |
|
|
In the derived model from code scenario probably all references would
use this extension. It seems a good idea if there was a central method
in either Resource or ResourceSet to customize the resolution (in
addition to allowing overloading on a meta-class basis). I am not sure
whether it would be a good idea to also use some magic URI letter to
trigger different resolution strategy. In the scenario there is
definitely a custom Resource implementation for serializing the resource
and perhaps that would suggest Resource as a natural place. One reason I
say this is that it doesn’t seem as simple to use a customized
ResourceSet in the generated Editor. I believe this requires to manually
fix code up after each regeneration.
Here is some more background for question 1, which was how do we know
the meta-type of the supplier at load time when the proxy is established.
As an example, a programming language syntax may not allow to identify
whether a type reference’s supplier is expected to be an interface or
class. Now if interfaces and classes are represented as different
meta-classes we don’t know the effective meta-type until after the
costly type resolution.
In this example one could define a common ancestor class (or mixin) such
as a classifier from which both derive. The proxy would be an instance
of classifier. After resolution it would be replaced by the effective
concrete meta-class (interface or class). Is this “meta-class-morphing”
an issue?
For languages where one cannot naturally conjure up a particular common
meta class one might want to allow declaring the features supplier as
EObject. I had a separate posting about modeling references to EObject.
This is quite tedious (using Rose at least) and I wonder whether it is
worthwhile to somehow special case this to make that easier.
There may also be other alternatives such as being able to specify a set
of possible meta-types that a reference may resolve to.
Finally I want to mention that method public static EObject
EcoreUtil.resolve(EObject proxy, Resource resourceContext) seems not to
be used.
Ed Merks wrote:
> Henrich,
>
> It would be interesting if InternalEObject had an eResolve method that took a
> proxy EObject as an argument. The code that calls EcoreUtil.resolve now would
> call this method directly and the default implementation of it would just call
> EcoreUtil.resolve, but a derived implementation could get fancy, i.e., you could
> just encode the identifier. This would require changing the templates and some
> of the built-in list implementations to use this new mechanism, but it all seems
> pretty straight forward, has very little cost, and provides significant new
> flexibility and potential performance improvements. I'll discuss this with the
> team...
>
> I didn't really understand your issue 1. A proxy EObject has to be of the right
> type to be able to add/set it to the feature that it needs to live in. You do
> not need to know the ultimate derived type of the object to which it will
> resolve. Since you know the feature you are putting the proxy into (I guess),
> you have all the type information you need. If I still haven't answered the
> question, could you please rephrase it?
>
>
> Henrich Kraemer wrote:
>
>
>>I just realized that only a string is passed into Resource.getEObject. I
>>think for the described scenario the approach to recompute all the
>>information would be superior in both space and time. However one would
>>need a hook into resolution where the proxy object is passed so that one
>>wouldn't have to find it first.
>>Is there a way to achieve this?
>>If there isn't a hook yet in EMF perhaps EMF could be extended to
>>support this of resolution which is context driven and has to be
>>provided entirely by the model implementer. Does this make sense to you?
>>
>>Of course issue 1 should be addressed as well....
>>
>>Henrich Kraemer wrote:
>>
>>
>>>It isn’t clear to me whether your suggestion address issue 1, does it?
>>>
>>>It seems one can compute parts from URI from the parent or broader
>>>context of the proxy supplier. If the meta-model captures the original
>>>text (identifier) one could actually compute all parts of the URI. In
>>>this case it seems it would be sufficient to just store “?” in the URI.
>>>This would delay even more computation and keep the memory requirements
>>>even lower.
>>>Is this a feasible trade-off?
>>>
>>>
>>>Ed Merks wrote:
>>>
>>>
>>>>Henrich,
>>>>
>>>>This is a very interesting question. Clearly you need to encode enough
>>>>information in the proxy URI that a reference can be resolved at a later
>>>>point in time. One approach would be to encode something like this:
>>>>
>>>>
>>>><uri-of-point-of-reference>#?<identifier>@<fragment-of-point-of-reference >
>>>>
>>>>
>>>>You would encode the resource containing the identifier reference, the
>>>>identifier that will need to be resolved, and the specific object
>>>>representing the location in the resource at which you want to resolve
>>>>the
>>>>identifier.
>>>>
>>>>In your specialized resource, you could override getEObject to
>>>>recognize the
>>>>above special syntax, i.e., fragments starting with "?". You'd use the
>>>>fragment portion after the "@" to find the object in the resource, and
>>>>then
>>>>you'd resolve the identifier relative to that object to yield your final
>>>>result, which can of course be an object in a different resource.
>>>>
>>>>
>>>>Henrich Kraemer wrote:
>>>>
>>>>
>>>>
>>>>>Consider one wants to add support for a programming language in eclipse
>>>>>similar to the JDT/CDT. One option would be to use EMF to represent the
>>>>>code.
>>>>>The primary form of code is text files and thus the EMF is derived from
>>>>>the code. As an example consider a file containing among other stuff
>>>>>the following text.
>>>>>...
>>>>>class A: public Stack {
>>>>>...
>>>>>
>>>>>When the tool needs to visualize or manipulate the code it instantiates
>>>>>an EMF model corresponding to the program text. Let’s assume that each
>>>>>file becomes an EMF resource. This would mean that the EMF code model’s
>>>>>implementation would provide its own ResourceImpl which will parse the
>>>>>code and create the appropriate EMF objects.
>>>>>
>>>>>Say the EMF code model would represent a class as CodeClass. Therefore
>>>>>the resource would contain an instance of CodeClass named ‘A’. CodeClass
>>>>>contains an EReference with multiplicity 0..1 called base which points
>>>>>to CodeClass.
>>>>>
>>>>>During loading of the EMF resource the reference will and should be
>>>>>lazily resolved and therefore a proxy should be created.
>>>>>
>>>>>I believe the default EMF mechanism assumes that one knows the following
>>>>>when a proxy is created:
>>>>>1. What meta-type the supplier is going to be. The proxy-object is of
>>>>>that supertype.
>>>>>2. Which resource the supplier is going to be in.
>>>>>3. Where exactly in the resource the proxy is at.
>>>>>2 and 3 are stored as an URI in eProxiURI with the format of
>>>>>“resource#fragment” on the proxy object.
>>>>>
>>>>>In contrast to the links found in EMF-XML documents all these questions
>>>>>cannot be easily answered for code. It requires to actually locate the
>>>>>Stack given imports project references etc. This is an expensive
>>>>>operation that should be delayed to EReference resolution time.
>>>>>
>>>>>How can this be achieved?
>>>>
>>>>
>>>>
>
|
|
|
| Re: Deriving EMF from code: how to delay resolving types? [message #380536 is a reply to message #380527] |
Thu, 13 November 2003 10:58 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
--------------4B863F0B0D573EB5867159AD
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Henrich,
The central place to override resolution is to override Resource.getEObject. Using
magic letters in the fragment is good if you want to support fragment paths, IDs, and
something else too. A customized resource set may be useful for other purposes.
Modifying the generated editor should not be a concern since the generated editor
really doesn't change as your model changes, i.e., only if we change the templates
would regeneration produce a different result.
You could have a proxy of type MyClassifier, that when resolved is replaced with an
object of type MyClass or MyInterface, i.e., any subclass of MyClassifier. Since your
proxy will need to be added/set to some EReference x, and since x.getEReferenceType()
yields the EClass that specifies the type of subclass of EObject that's allowed in the
reference, as long as that EClass if not abstract, you'll have a type of object you can
create to act as a proxy. There really won't be any problem either if you had a proxy
of type MyClass that when resolved becomes an object of type MyInterface, all that
matters is that the proxy and the result conform to the type of the feature.
We don't generate references to EcoreUtil.resolve(EObject proxy, Resource
resourceContext), but that doesn't mean no one uses it. Since the other versions of
resolve all must walk up to the resource set, in situations where you already know the
"root" resource set, it will be much faster to go to it directly.
In the 2.0 stream you will be able to have an attribute of type EObject in your Rose
model without importing the Ecore model and it will be converted to an EReference of
type EObject (just as an attribute of type String is converted to EString
automatically).
If the idea of providing a method
EObject eResolveProxy(InternalEObject proxy)
in InternalEObject is something that you feel would useful to help solve your problem
more efficiently---it seems that it would---please open a bugzilla request. I've
talked to Frank about the idea and he was happy with it. Until you have this feature,
going with the approach of encoding enough information in the URI to work your way back
to the proxy holder, will help get you going.
Henrich Kraemer wrote:
> In the derived model from code scenario probably all references would
> use this extension. It seems a good idea if there was a central method
> in either Resource or ResourceSet to customize the resolution (in
> addition to allowing overloading on a meta-class basis). I am not sure
> whether it would be a good idea to also use some magic URI letter to
> trigger different resolution strategy. In the scenario there is
> definitely a custom Resource implementation for serializing the resource
> and perhaps that would suggest Resource as a natural place. One reason I
> say this is that it doesn
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 07:50:52 GMT 2024
Powered by FUDForum. Page generated in 0.03501 seconds |
] 
Search
Help
Register
Login
Home
