[furcas-discussion] Reference Re-Evaluation Algorithm

Mon Feb 14 08:35:35 CET 2011

Sounds like a plan, should we schedule an on-site meeting for that? What 
do you think?

Thomas Goldschmidt 

ABB AG
Forschungszentrum
Wallstadter Straße 59
68526 Ladenburg
Office Phone: +49 6203 716134
Office Fax: +49 6203 716253
e-mail: thomas.goldschmidt at de.abb.com

ABB AG
Sitz/Head Office: Mannheim 
Registergericht/Registry Court: Mannheim
Handelsregisternummer/Commercial Register No.: HRB 4664
Geschäftsführung/Managing Board: Peter Smits (Vorsitzender), Joachim 
Schneider, Markus Ochsner, Hans-Georg Krabbe
Vorsitzender des Aufsichtsrats/Chairman of Supervisory Board: Bernhard 
Jucker

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht gestattet. 

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

Axel Uhl <axel.uhl at gmx.de> 
Sent by: furcas-discussion-bounces at lists.furcas.org
11.02.2011 20:57

To
Stephan Erb <stephan at dev.static-void.de>
cc
furcas-discussion <furcas-discussion at lists.furcas.org>
Subject
Re: [furcas-discussion] Reference Re-Evaluation Algorithm

+1

On 02/11/2011 08:35 PM, Stephan Erb wrote:
> Hey Axel,
>
> I have no clue. Your proposal sounds reasonable to me but I wouldn't bet
> on it, given the fact that sometimes TextBlocks are merged if they don't
> contribute to the concrete syntax.
>
> This discussion somewhat implies to me that we are wasting our energy:
> Our second-most important data structure, the TextBlocks model, is so
> complex and underspecified that we constantly struggle with it.
>
> I would suggest that we try to redesign the TextBlocks model so that it
> is easier to handle. For example, each TextBlock could have exactly one
> corresponding ModelElement. If TextBlocks contain no concrete syntax,
> then they would simply have no subnodes.  I guess we can think of even
> more simplifications.
>
> This is additional short term effort, but I am very sure it is a
> worthwhile investment.
>
>
> Best Regards,
> Stephan
>
>
> On Fri, 2011-02-11 at 17:19 +0100, Uhl, Axel wrote:
>> Stephan,
>>
>> thinking about this again suggest something else. I don't think we want 
to rely on the token's referencedElements to be set in order to determine 
whether the token is the one that belongs to the update notification 
received. The token may be stale anyway because it was in some remote 
resource that didn't get updated upon an earlier change.
>>
>> Instead, we should be looking for the token's parent text blocks. They 
should lead to a text block, ultimately, whose corresponding model element 
is the one to be updated with the resolution of the token, shoulnd't it?
>>
>> I'm just uncertain again how the LexedToken may be nested inside 
TextBlocks. Can I assume that the LexedToken's getParent() is the template 
that has in its correspondingModelElements the element to be updated with 
the property?
>>
>> -- Axel
>>
>>> -----Original Message-----
>>> From: furcas-discussion-bounces at lists.furcas.org [mailto:furcas-
>>> discussion-bounces at lists.furcas.org] On Behalf Of Stephan Erb
>>> Sent: Friday, February 11, 2011 3:12 PM
>>> To: furcas-discussion
>>> Subject: Re: [furcas-discussion] Reference Re-Evaluation Algorithm
>>>
>>>>> PS: Thomas, we might need your help with all this textblocks magic
>>>>> (e.g.
>>>>> find out if a reference is still bound). Expect some questions on
>>> the
>>>>> mailing list rather soon :-)
>>>>
>>>> I found that out myself. In this case it was an easy reverse lookup
>>> on DocumentNode_SequenceElement using the OppositeEndFinder API.
>>>
>>> Hi Axel,
>>>
>>> I just had a (very) short look at the OCLQueryPropertyUpdate. Is there
>>> a
>>> reason why the 'referencedElements' aren't checked anywhere? I always
>>> thought that those entail the crucial information whether a token is
>>> bound to something or not.
>>>
>>> Example from the MOIN code base where used them:
>>>
>>>      private Collection<?>  findCurrentlySetElements(DelayedReference
>>> unresolvedRef, ModelInjector modelInjector,
>>>                  LexedToken tokenInCurrentConnection) throws
>>> ModelAdapterException {
>>>
>>>              Collection<?>  valueCollection =
>>> modelInjector.getModelAdapter().get(unresolvedRef.getModelElement(),
>>> unresolvedRef.getPropertyName());
>>>              if (tokenInCurrentConnection != null) {
>>>
>>> 
valueCollection.retainAll(tokenInCurrentConnection.getReferencedElement
>>> s());
>>>              }
>>>              return valueCollection;
>>>      }
>>>
>>> Best,
>>> Stephan
>>>
>>>
>>>
>>> _______________________________________________
>>> Furcas-discussion mailing list
>>> Furcas-discussion at lists.furcas.org
>>> http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion
>
>

-- 
Find Security Certificate at http://www.axel-uhl.de/cgi-bin/cacert.cgi

[attachment "smime.p7s" deleted by Thomas Goldschmidt/DEABB/ABB] 
_______________________________________________
Furcas-discussion mailing list
Furcas-discussion at lists.furcas.org
http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.furcas.org/pipermail/furcas-discussion/attachments/20110214/4e4b1264/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 454 bytes
Desc: not available
URL: <http://lists.furcas.org/pipermail/furcas-discussion/attachments/20110214/4e4b1264/attachment.gif>