Eclipse Community Forums: TMF (Xtext) » semantic change to resource with unresolved references

Help

Home

Home » Modeling » TMF (Xtext) » semantic change to resource with unresolved references

Show: Today's Messages :: Show Polls :: Message Navigator

semantic change to resource with unresolved references [message #858821]

Fri, 27 April 2012 10:01

Knut Wannheden

Messages: 298
Registered: July 2009

Senior Member

Hi,

I have a question regarding semantic modifications to resources containing
unresolved lazy linking references.

When applying a semantic modification to a resource (e.g. using a semantic
quick fix) it is possible that the resource contains some unresolved lazy
linking references (i.e. "xtextLink_" proxies). The problem with these is that
the modification may invalidate the proxy URIs as they contain a path to the
object owning the reference, which may have changed as a result of the
modification.

The problem typically manifests itself as errors logged by LazyLinkingResource
("resolution of uriFragment 'xtextLink_::...' failed.") when serializing the
resource after the modification. But it could of course be worse: The URIs
could actually point to some other object in the AST and the serializer could
serialize the wrong thing.

I am looking into approaches to deal with this problem. Basically the
following come to mind:

1. Don't allow semantic modifications when the resource contains unresolved
lazy linking references. This of course works but is quite limiting. The JDT
doesn't have any problems with this nor would Xtext if the unresolved
references had a "normal" URI.

2. Fixup all unresolved lazy linking references after (or as part of) the
semantic change. This seems like a rather nasty thing to do...

Does anyone have experience with this problem or knows of other solutions?

Thanks,

--knut

Report message to a moderator

Re: semantic change to resource with unresolved references [message #859014 is a reply to message #858821]

Fri, 27 April 2012 12:09

Sebastian Zarnekow

Messages: 3108
Registered: July 2009

Senior Member

Hi Knut,

a #resolveAll prior to the semantic modification seems the way to go.
Another possibility is to adapt the lazy linking uris, e.g by
introducing some sort of object to id map where the linking uri just
holds the id of an object which was previously put into that map. Those
should be pretty stable.
Other options don't come to my mind.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 27.04.12 12:01, schrieb Knut Wannheden:
> Hi,
>
> I have a question regarding semantic modifications to resources
> containing unresolved lazy linking references.
>
> When applying a semantic modification to a resource (e.g. using a
> semantic quick fix) it is possible that the resource contains some
> unresolved lazy linking references (i.e. "xtextLink_" proxies). The
> problem with these is that the modification may invalidate the proxy
> URIs as they contain a path to the object owning the reference, which
> may have changed as a result of the modification.
>
> The problem typically manifests itself as errors logged by
> LazyLinkingResource ("resolution of uriFragment 'xtextLink_::...'
> failed.") when serializing the resource after the modification. But it
> could of course be worse: The URIs could actually point to some other
> object in the AST and the serializer could serialize the wrong thing.
>
> I am looking into approaches to deal with this problem. Basically the
> following come to mind:
>
> 1. Don't allow semantic modifications when the resource contains
> unresolved lazy linking references. This of course works but is quite
> limiting. The JDT doesn't have any problems with this nor would Xtext if
> the unresolved references had a "normal" URI.
>
> 2. Fixup all unresolved lazy linking references after (or as part of)
> the semantic change. This seems like a rather nasty thing to do...
>
> Does anyone have experience with this problem or knows of other solutions?
>
> Thanks,
>
> --knut

Report message to a moderator

Re: semantic change to resource with unresolved references [message #859044 is a reply to message #859014]

Fri, 27 April 2012 12:30

Knut Wannheden

Messages: 298
Registered: July 2009

Senior Member

Hi Sebastian,

Performing a #resolveAll() prior to the modification is certainly a good idea.
What I forgot to mention in the original post is that it's *unresolvable* lazy
linking references causing the headache. These would of course remain
unresolved after a #resolveAll().

So it's down to either some kind of stabler ID mapping like you propose or a
fixup of the lazy linking URIs. Neither seems very appealing... Your approach
has the advantage that it would be transparent to the client. But it would
require another map, preferably with weak references to the EObjects.

Regards,

--knut

On 4/27/12 2:09 PM, Sebastian Zarnekow wrote:
> Hi Knut,
>
> a #resolveAll prior to the semantic modification seems the way to go.
> Another possibility is to adapt the lazy linking uris, e.g by introducing some
> sort of object to id map where the linking uri just holds the id of an object
> which was previously put into that map. Those should be pretty stable.
> Other options don't come to my mind.
>
> Regards,
> Sebastian

Report message to a moderator

Re: semantic change to resource with unresolved references [message #859068 is a reply to message #859044]

Fri, 27 April 2012 12:43

Ed Willink

Messages: 6772
Registered: July 2009

Senior Member

Hi Knut

You may find the extra map has other advantages.

For OCL where there are distinct Concrete Syntax Trees (from Xtext) and
Abstract Syntax Trees (for the specification), I maintain a CSI
(Concrete Syntax Identifier) to AST element map, so that after an Xtext
edit the often substantially changed CST can be correlated against its
predecessor to drive a refresh of the AST. This avoids violating the
Xtext prohibition on maintaining references to the CST. The algorithm
for computing the CSI (rather than the URI) is a free choice so long as
each CST node acquires a unique and desirably stable refactorable identity.

Regards

Ed Willink

On 27/04/2012 13:30, Knut Wannheden wrote:
> Hi Sebastian,
>
> Performing a #resolveAll() prior to the modification is certainly a
> good idea. What I forgot to mention in the original post is that it's
> *unresolvable* lazy linking references causing the headache. These
> would of course remain unresolved after a #resolveAll().
>
> So it's down to either some kind of stabler ID mapping like you
> propose or a fixup of the lazy linking URIs. Neither seems very
> appealing... Your approach has the advantage that it would be
> transparent to the client. But it would require another map,
> preferably with weak references to the EObjects.
>
> Regards,
>
> --knut
>
> On 4/27/12 2:09 PM, Sebastian Zarnekow wrote:
>> Hi Knut,
>>
>> a #resolveAll prior to the semantic modification seems the way to go.
>> Another possibility is to adapt the lazy linking uris, e.g by
>> introducing some
>> sort of object to id map where the linking uri just holds the id of
>> an object
>> which was previously put into that map. Those should be pretty stable.
>> Other options don't come to my mind.
>>
>> Regards,
>> Sebastian
>

Report message to a moderator

Re: semantic change to resource with unresolved references [message #859158 is a reply to message #859068]

Fri, 27 April 2012 13:37

Knut Wannheden

Messages: 298
Registered: July 2009

Senior Member

Hi Ed

Thanks for the input.

I've now implemented a custom LazyURIEncoder returning fragments like
"xtextLink_::42" where 42 is the index in a List<Triple<EObject, EReference,
INode>> which is a field declared by the LazyLinkingResource object.

This makes both URI encoding and decoding very fast. Also all lazy linking
proxies of a resource can be resolved very easily in
#resolveLazyCrossReferences() by simply iterating over this list.

Of course the URIs are very cryptic and not serializable, but that may not be
a requirement. On the positive side this results in a small performance boost.

Regards,

--knut

On 4/27/12 2:43 PM, Ed Willink wrote:
> Hi Knut
>
> You may find the extra map has other advantages.
>
> For OCL where there are distinct Concrete Syntax Trees (from Xtext) and
> Abstract Syntax Trees (for the specification), I maintain a CSI (Concrete
> Syntax Identifier) to AST element map, so that after an Xtext edit the often
> substantially changed CST can be correlated against its predecessor to drive a
> refresh of the AST. This avoids violating the Xtext prohibition on maintaining
> references to the CST. The algorithm for computing the CSI (rather than the
> URI) is a free choice so long as each CST node acquires a unique and desirably
> stable refactorable identity.
>
> Regards
>
> Ed Willink
>

Report message to a moderator

Re: semantic change to resource with unresolved references [message #859470 is a reply to message #859158]

Fri, 27 April 2012 16:54

Sebastian Zarnekow

Messages: 3108
Registered: July 2009

Senior Member

Hi Knut,

I like that approach. Do you have some numbers on the small performance
boost of #resolveLazyCrossReferences? I'd expect a small percentage
around 2 or 3? More importantly it seems to reduce the complexity of the
uri encoding / decoding algorithm.
Actually I find the shorter version of the lazy linking uri more
readable than the actual notation.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 27.04.12 15:37, schrieb Knut Wannheden:
> Hi Ed
>
> Thanks for the input.
>
> I've now implemented a custom LazyURIEncoder returning fragments like
> "xtextLink_::42" where 42 is the index in a List<Triple<EObject,
> EReference, INode>> which is a field declared by the LazyLinkingResource
> object.
>
> This makes both URI encoding and decoding very fast. Also all lazy
> linking proxies of a resource can be resolved very easily in
> #resolveLazyCrossReferences() by simply iterating over this list.
>
> Of course the URIs are very cryptic and not serializable, but that may
> not be a requirement. On the positive side this results in a small
> performance boost.
>
> Regards,
>
> --knut
>
> On 4/27/12 2:43 PM, Ed Willink wrote:
>> Hi Knut
>>
>> You may find the extra map has other advantages.
>>
>> For OCL where there are distinct Concrete Syntax Trees (from Xtext) and
>> Abstract Syntax Trees (for the specification), I maintain a CSI (Concrete
>> Syntax Identifier) to AST element map, so that after an Xtext edit the
>> often
>> substantially changed CST can be correlated against its predecessor to
>> drive a
>> refresh of the AST. This avoids violating the Xtext prohibition on
>> maintaining
>> references to the CST. The algorithm for computing the CSI (rather
>> than the
>> URI) is a free choice so long as each CST node acquires a unique and
>> desirably
>> stable refactorable identity.
>>
>> Regards
>>
>> Ed Willink
>>
>
>

Report message to a moderator

Re: semantic change to resource with unresolved references [message #865707 is a reply to message #859470]

Mon, 30 April 2012 14:25

Knut Wannheden

Messages: 298
Registered: July 2009

Senior Member

Hi Sebastian,

On 4/27/12 6:54 PM, Sebastian Zarnekow wrote:
>
> I like that approach. Do you have some numbers on the small performance boost
> of #resolveLazyCrossReferences? I'd expect a small percentage around 2 or 3?

Right on the spot :-) 2 to 3 percent is what I measured. The linking phase of
the resource loading probably benefits the most from this change, as the lazy
linking URIs are faster to compute.

> More importantly it seems to reduce the complexity of the uri encoding /
> decoding algorithm.
> Actually I find the shorter version of the lazy linking uri more readable than
> the actual notation.
>

I quite like this as well. It probably comes at the price of a small memory
increase (the additional Triple objects and the List or Map object in the
resource) but I think the benefits (i.e. safe semantic modifications in
resources with unresolvable references) outweigh this.

I will file an enhancement request.

Regards,

--knut

Report message to a moderator

Previous Topic:	[SOLVED] Referencing Java methods by annotation
Next Topic:	Modifying a file that's not open in an editor?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Jul 11 12:23:45 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter