|
|
|
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: 7655 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
>
|
|
|
|
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: 3118 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
>>
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02170 seconds