Issue 14620: QVT 1.1 Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution) (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: The resolution for Issue 12375 specifies that ListLiteralExp has CollectionLiteralExp as a superclass. This leaves the behaviour of the inherited kind and part attributes unspecified and rather embarrassing. ListLiteralExp (like DictLiteralExp) should inherit directly from LiteralExp. Resolution: Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution) The resolution for Issue 12375 specifies that ListLiteralExp has CollectionLiteralExp as a superclass. This leaves the behaviour of the inherited kind and part attributes unspecified and rather embarrassing. ListLiteralExp (like DictLiteralExp) should inherit directly from LiteralExp. Discussion The lack of specification of ListLiteralExp::kind and ListLiteralExp::part is indeed a problem. CollectionLiteralExp::kind is inextensible bloat that OCL could usefully eliminate, so no ListLiteralExp::kind is needed in QVTo. ListLiteralExp::part is needed if QVTo is truly an extension of OCL. Unfortunately the QVTo BNF omits the ".." operator and support for CollectionRanges. Therefore we need to introduce the missing CollectionRange parsing. ListLiteralExp can inherit LiteralExp adding CollectionLiteralExp::part but not CollectionLiteralExp::kind. ListLiteralExp::element is misguided; ListLiteralExp::part replaces it. Revised Text: In the QVTo model and Fig 8.11, where ListLiteralExp already inherits directly from LiteralExp, replace element:OclExpression[*]{composes,ordered} by part:CollectionLiteralPart[*]{composes,ordered} In 8.2.2.29 ListLiteralExp replace the CollectionLiteralExp superclass by LiteralExp, and replace element:OclExpression[*]{composes,ordered} by part:CollectionLiteralPart[*]{composes,ordered} In 8.4.7 BNF replace <collection_item_list> ::= <expression_comma_list> by <collection_item> ::= <expression> ('..' <expression>)? <collection_item_list> ::= <collection_item> (',' <collection_item>)* Add to 8.2.2.24 ListType: Notation An initialized list literal may be created in the same way as an initialized sequence literal. List{1,2,3} List{1..10,12,14..16} Implementation Note ListLiteralExp will become obsolete once OCL eliminates the prohibition on extension of CollectionLiteralExp imposed by the redundant CollectionLiteralExp::kind attribute. Actions taken: November 11, 2009: received issue December 22, 2015: Resolved March 29, 2016: closed issue Discussion: End of Annotations:===== m: "Willink, Ed" To: "'issues@omg.org'" Subject: QVT 1.1 Inappropriate ListLiteralExp inheritance (Correction to I ssue 12375 resolution) Date: Wed, 11 Nov 2009 11:26:42 -0000 X-Mailer: Internet Mail Service (5.5.2657.72) Hi The resolution for Issue 12375 specifies that ListLiteralExp has CollectionLiteralExp as a superclass. This leaves the behaviour of the inherited kind and part attributes unspecified and rather embarrassing. ListLiteralExp (like DictLiteralExp) should inherit directly from LiteralExp. Regards Ed Willink **************************************************************************** Please consider the environment before printing this email. **************************************************************************** Thales Research and Technology (UK) Limited DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained herein. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0)1293 575987 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. The registered office of Thales Research and Technology (UK) Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered in England No. 774298. ****************************************************************************