[great-users] be careful with crosslink rolenames

[Attila Vizhanyo]

Thanks Matt for calling our attention to this hidden implementation feature.

Here is a list of reserved names in Udm. You cannot use these names as 
association role names when specifying a UML class diagram.
- Instances
- Derived
- ArcheType
- instances
- derived
- archetype
- hasRealArchetype
- isInstance
- isSubtype
- __impl
- type
- uniqueId
- container
- GetAdjacentObjects
- GetAdjacentUniqueObjects
- GetParent
- GetChildObjects
- GetPeersFromAssociationClassObject
- DeleteObject

Thanks,
Attila



Matthew J. Emerson wrote:

> It’s possible to introduce errors in your GReAT transformation if some 
> of your crosslink rolenames happen to override method names inherited 
> from Udm::Object.
>
> For example, in a language of mine I have the notion of data type 
> inheritance hierarchies. So, for shorthand in my GreAT transformation, 
> I implemented the following crosslink:
>
> The trouble comes in from the source rolename of the connection, 
> ‘type’. This is the code generated for MyLanguage::DataType to handle 
> the navigation of the crosslink in that direction:
>
> Udm::CrossAssocAttr<C4ISR::DataType> type() const { return 
> Udm::CrossAssocAttr<C4ISR::DataType>(impl, meta_type); }
>
> And here is the definition of the same method from Udm::Object:
>
> virtual const Uml::Class &type() const { throw e; }
>
> Uh-oh! I ended up overriding a Udm::Object method which, because I 
> don’t ever program using UDM, I’ve never even heard of!
>
> This causes some compiler errors to crop up in the generated 
> transformation code. For example, in the middle of a generated 
> pattern-matching function for one of my transformation rules, I find:
>
> [SNIP]
>
> for( set< MYLANG::DataType>::const_iterator 
> itMYLANG_Derived_Composites_228= MyLang_Derived_Composites_227.begin();
>
> itMYLANG_Derived_Composites_228!= MyLang_Derived_Composites_227.end(); 
> ++itMYLANG_Derived_Composites_228)
>
> {
>
> if( false== Uml::IsDerivedFrom( 
> (*itMYLANG_Derived_Composites_228).type(), MYLANG::Composite::meta))
>
> continue;
>
> [SNIP]
>
> In this case, the call to MYLANG::DataType::type has a different 
> return type than expected for the first parameter of 
> Uml::IsDerivedFrom. This one isn’t so hard to figure out, but I can 
> imagine the case where you override a Udm::Object method that happens 
> to have the exact same signature as the overriding method. In that 
> case, the transformation would successfully compile and do 
> God-knows-what, and I pity the person who has to debug /that/.
>
> This problem is probably pretty rare, but one way to avoid it is to 
> alter the way code is generated to be more explicit about which 
> functions you intend to call. For example, the code above could have 
> been generated as:
>
> [SNIP]
>
> for( set< MYLANG::DataType>::const_iterator 
> itMYLANG_Derived_Composites_228= MyLang_Derived_Composites_227.begin();
>
> itMYLANG_Derived_Composites_228!= MyLang_Derived_Composites_227.end(); 
> ++itMYLANG_Derived_Composites_228)
>
> {
>
> if( false== Uml::IsDerivedFrom( 
> (Udm::Object(*itMYLANG_Derived_Composites_228)).type(), 
> MYLANG::Composite::meta))
>
> continue;
>
> [SNIP]
>
> That would have ensured that the intended method gets called. However, 
> it’s probably not feasible to correct every case where a Udm::Object 
> method call is produced by the code generator to avoid these rare 
> errors…so, the conclusion is, don’t override method names from 
> Udm::Object with crosslink rolenames (or metamodel attribute names, 
> which would cause the same problem).
>
> --Matt
>
>------------------------------------------------------------------------
>
>_______________________________________________
>great-users mailing list
>great-users at list.isis.vanderbilt.edu
>http://list.isis.vanderbilt.edu/mailman/listinfo/great-users
>  
>