[news.eclipse.tools.emf] Re: TraversalStrategy's double visits

["John J. Franey" <jjfraney@xxxxxxxxx>]

On Thu, 17 Sep 2009 12:21:46 -0400, Ed Merks wrote:

> John,
> 
> Comments below.

Thanks.  I have a question, see below.

>
>> So, with the input I provided, the first call to ATI.next ought to
>> return a 'component' eobject.
> Not sure what input you provided.

The input is this xml content:
>>>> <?xml version="1.0" encoding="UTF-8"?> <scr:component
>>>>   xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"; enabled="true"
>>>>   factory="" immediate="false" name="Command Provider for Dictionary
>>>>   Service" activate=""
>>>>   deactivate=""
>>>>   modified="">
>>>>      <implementation class="jjjjjjjjjj"/>
>>>>      <service/>
>>>> </scr:component>



>> Here is the iterator's value of eStructuralFeatures array whose length
>> is 4:
>>
>> org.eclipse.emf.ecore.impl.EAttributeImpl@61328229 (name: mixed)
>> (ordered: true, unique: false, lowerBound: 0, upperBound: -1)
>> (changeable: true, volatile: false, transient: false,
>> defaultValueLiteral: null, unsettable: false, derived: false) (iD:
>> false)
>>
>> org.eclipse.emf.ecore.impl.EReferenceImpl@26b056fd (name:
>> implementation) (ordered: true, unique: true, lowerBound: 1,
>> upperBound: 1) (changeable: true, volatile: true, transient: true,
>> defaultValueLiteral: null, unsettable: false, derived: false)
>> (containment: true, resolveProxies: false)
>>
>> org.eclipse.emf.ecore.impl.EReferenceImpl@2a8e32b7 (name: service)
>> (ordered: true, unique: true, lowerBound: 0, upperBound: 1)
>> (changeable: true, volatile: true, transient: true,
>> defaultValueLiteral: null, unsettable: false, derived: false)
>> (containment: true, resolveProxies: false)
>>
>> org.eclipse.emf.ecore.impl.EReferenceImpl@3aff8399 (name: reference)
>> (ordered: true, unique: true, lowerBound: 0, upperBound: -1)
>> (changeable: true, volatile: true, transient: true,
>> defaultValueLiteral: null, unsettable: false, derived: false)
>> (containment: true, resolveProxies: false)
>>
>> It looks like the iterator retrieves the first 'implementation' and
>> 'service' eObjects as result of interpreting the first element in
>> eStructuralFeatures.  The second 'implementation' comes from
>> interpreting the second element of eStructuralFeatures.  The second
>> 'service' comes from interpreting the third element of
>> eStructuralFeatures.  I can give details of this debugging session. 
>> Its painstaking.  I hope I don't have to do it.
>>   
> I don't think it's possible for an object to be contained by more than
> one containment feature. 

Which stands in conflict with your understanding: the eStructuralFeatures 
above, my analysis, or both?

> But shouldn't all these other references be
> marked as derived given they are derived from the mixed feature map (I
> assume).

Your assumption may be correct.  I did not originate the model.  I hope 
you don't mind me asking what led you to that assumption?

My other question is more of a clarification.  When you say 'marked as 
derived', I think you mean each of the EReferences above ought to have 
the flag 'derived' set to 'true'.

I wonder how the author of an ecore model would know to mark such 
references as 'derived'.

Finally, what connects a 'derived field' to the associated feature map 
and key?  I mean, when I look at the ecore xml file, I see a structural 
feature element for one of the references above, but I can't see how 
ecore knows how to generate the get method to reach into the map and what 
key to use.



>>
>> So the question: is the iterator being initialized incorrectly
>> (incorrect content of eStructuralFeatures), or does it interpret
>> eStructuralFeatures incorrectly?
>>   
> I think they fact they aren't derived is a problem.  How did this model
> arise?

I have to bring up that question with the person who originated the 
model.  From the plugin project's setup, it appears that the ecore file 
is the source of the model.


Thanks again,
John