Re: RefersToImpl

Hi Brian,
I agree that this was not the cleanest thing to do. I will probably turn 
this off by default and make it possible to enable it using some system 
property. The reason why I implemented this is that currently we are 
using Rational Rose with a plugin from Unisys to generate our metamodels 
and this plugin is not keeping the references in sync with association 
ends (i.e. if I change multilicity/changeability of association end, it 
still generates the reference with the old multiplicity). Because having 
to explicitly list all the references (we are using implicit references 
generation) would be too much work and it is also common for other tools 
to have association ends inconsistent with references, I fixed it by 
updating the reference automatically. Also this is the reason why the 
synchronization happens only when you associate a reference with an 
association end - it comes into play only when loading a metamodel from 
XMI. After that, you are welcome to make the attributes inconsistent in 
anyway you want. In fact, if MOF 1.4 would support features overriding, 
I believe these attributes in reference would be overriden to be derived 
from the association end's attributes.
But anyway, you are right that this behavior is not correct - I will 
remove it...
Martin

Brian Smith wrote:
> Hi,
> 
> I'm curious about why the change was made to RefersToImpl to 
> automatically sync the reference's attributes (isChangeable, 
> multiplicity) to match the attribute that it links to. I think this 
> behavior is really suprising, given:
> 
> (a) The constraints that this behavior supports are deferred. I guess it 
> isn't defined in the spec, but presumably it should be okay for the 
> values of these attributes to be different until 
> refVerifyConstraints(...) is called on the reference and/or the 
> association.
> 
> (b) The behavior is not consistent among the Reference-AssociationEnd 
> constraints like ReferenceTypeMustMatchEndType (the reference's type 
> chould be set the same as the associations), 
> ReferencedEndMustBeNavigable (adding a reference to an association end 
> could presumably make it navigable).
> 
> (c) It goes against the "style guide" in the MOF 1.4 spec (4.13.3 Update 
> operations should only change the nominated metadata).
> 
> (d) If you change the reference's multiplicity/type/changeability after 
> the link has been added, will association's attributes change? (and vice 
> versa?)
> 
> (e) How do you know that the reference has the wrong values and the 
> association has the right ones?
> 
> Thanks,
> Brian
>