[furcas-discussion] Reference Re-Evaluation Algorithm

[Uhl, Axel]

I've now fixed the OCLQueryPropertyUpdater to the point that Sebastian's tests pass.

Could someone who's TextBlock-literate please review OCLQueryPropertyUpdater.getTokens(EObject)? I'm not certain that lt.getParent().getCorrespondingModelElements() always gives me the element to update if the token is applicable.

Nota bene: EObjectResolvingEList.contains(e) is not the same as EObjectResolvingEList.iterate().next() ==. Iterators use get(...) which internally calls resolve. contains(...), however, does not call resolve() which I consider a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=336970). You may want to use iterators and compare yourself instead of relying on contains(...) doing a resolve.

Best,
-- Axel

> -----Original Message-----
> From: furcas-discussion-bounces at lists.furcas.org [mailto:furcas-
> discussion-bounces at lists.furcas.org] On Behalf Of Uhl, Axel
> Sent: Friday, February 11, 2011 3:47 PM
> To: Stephan Erb
> Cc: furcas-discussion
> Subject: Re: [furcas-discussion] Reference Re-Evaluation Algorithm
> 
> Could you or Thomas check whether during the MOIN-EMF migration the
> code to set the referencedElement was properly migrated? I'll meanwhile
> add the code to the updater that sets the reference in the token.
> 
> > -----Original Message-----
> > From: Stephan Erb [mailto:stephan at dev.static-void.de]
> > Sent: Friday, February 11, 2011 3:36 PM
> > To: Uhl, Axel
> > Cc: furcas-discussion
> > Subject: RE: [furcas-discussion] Reference Re-Evaluation Algorithm
> >
> > The parser is supposed to set this reference, just like it sets the
> > corresponding model elements. It being always empty sounds like a bug
> > to
> > me...
> >
> > And yes, the updater should update the referencedElements according
> to
> > the unset/set elements.
> >
> > On Fri, 2011-02-11 at 15:29 +0100, Uhl, Axel wrote:
> > > Stephan,
> > >
> > >
> > > strangely, the tokens' referencedElements is always empty. Should
> > they be set?
> > >
> > > Should the updater set the referencedElement in the token when it
> > resolves successfully?
> > >
> > > -- 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
> >
> 
> _______________________________________________
> Furcas-discussion mailing list
> Furcas-discussion at lists.furcas.org
> http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion