Community
Participate
Working Groups
Due to some alignment with OCL Pivot metamodel changes a new undesired custom implementation is required in the generated Impl classes. OCL-Pivot TypedMultiplicityElement includes in its API a new (non-generated???????) isMany method. The corresponding TypedMultiplicityElementImpl contains a hand-written implementation of such a method. Due to multiple inheritance issues, VarParameterImpl is not completely auto-generated so it needs to "copy paste" the implementation from TypedMultiplicityElementImpl This bug is simply created to track the issue, study it, and conclude how to better solve it. For the time being, the VarParameterImpl will include the manual implementation. N.B: The suspicious API method needs discussion with Ed.
Elimination of the double inheritance is only possible with an OMG meta-model change. But at the OMG-level (equivalent to the Ecore Java interfaces) multiple inheritance is no problem. So why should OMG change just to make Java toolsmiths happy? Ecore happily auto-generates the multiples. Once the manual code is auto-generated from model specifications the problem may go away.
> > Ecore happily auto-generates the multiples. Once the manual code is > auto-generated from model specifications the problem may go away. That's what I'd expect/want. So far, the bug tracks the issue waiting for a completely autogenerated java classes for QVTo models. More importantly is the my concern about that TypedMultiplicityElement.isMany java API method which looks like to be "hand coded" since doesn't have the corresponding @generated, which perhaps merits its own bugzilla, although I'm happy with discussion via this one. Cheers, Adolfo.
The interesting Pivot *Impl classes currently average about 5 manual methods. Now that the OCL code generation is better many of the distinctive methods can be coded in OCL. That leaves accept, toString and perhaps getTypeId() for specialized codegen helpers.
