[furcas-discussion] referenceBy Use-Case

[Stephan Erb]

Hey Thomas,

I believe that we do already support this usecase:
> referenceBy="OCL:...anything goes here..."

Protocol is that the referenceBy expression returns a type covered by a
PrimitiveTemplate. 

We implemented it because in same rare circumstances you need more
complex rules to derive the name of an object, as for example within the
as-Argument of the TCS syntax.

Best,
Stephan

On Fri, 2011-02-25 at 09:02 +0100, Thomas Goldschmidt wrote:
> 
> Hi, 
> 
> I think I found a case where the current lookupScope/referenceBy
> handling might not enough: 
> 
> I have a syntax for the Ecore variant of OCL which is based on
> generics inheriting from a generic OCL metamodel (which is kind of
> ugly in my oppinion). Anyway, there I define a template for
> VariableExp in the fopllowing way: 
> 
> template "http://www.eclipse.org/ocl/1.1.0/Ecore"#VariableExp 
>         : [[ 
>              referredVariable {forcedLower=1,mode=self} 
>           | 
>              referredVariable  {as=identifier, forcedLower=1 ,
> lookupScope = "ocl::ecore::Variable.allInstances()",
> referenceBy="name"} 
>           ]] 
> 
>  {{ eType=lookIn("OCL:self.referredVariable.oclAsType(ocl::ecore::Variable).eType"), 
> 
> name=lookIn("OCL:self.referredVariable.oclAsType(ocl::ecore::Variable).name") }} 
>         ; 
> 
> However, this doesn't work as the referenceBy-feature "name" is
> currently validated against the type of the feature it is intended to
> set, i.e., referredVariable. In this setting referredVariable is typed
> as  Variable<C, PM>  from ocl::expressions (which is the generic part
> of OCL) where the generics are bound as <EClassifier, EParameter>.
> Still there is a concrete subclass of VariableExp in the ocl::ecore
> package defined as follows: Variable ->
> ETypedElement,Variable<EClassifier, EParameter>. This leads to the
> fact that "name" is only defined on this concrete subclass (inherited
> from ETypedElement->ENamedElement). Therefore, the "name" feature is
> not found when validating the syntax and an error occurs. Still, the
> generic Variable<C, PM> also inherits from the abstract class
> ocl::utilities::TypedElement which defines an operation "getName()".
> This "coincidence" leads to the fact that on the Java side this
> "getName()" magically works by resolving to ENamedElement.getName(),
> during OCL evaluation this also works fine if we call operation
> getName() instead of attribute "name". Therefore, what might work is
> using the operation in the referenceBy clause: 
> 
> referenceBy="getName()" 
> 
> What do you think? Is this just a weird special case that will never
> occur anywhere else? Or do we need to support this? 
> 
> Btw: Resolving generics as reference types was not supported in the
> generator, I added this including some test cases and I will push this
> later today. 
> 
> Cheers,
> Thomas
> 
>   
> 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.
> _______________________________________________
> Furcas-discussion mailing list
> Furcas-discussion at lists.furcas.org
> http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion