Issue 12948: Making OclAny denote any object (ocl2-rtf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com) Nature: Uncategorized Issue Severity: Summary: Summary: In the actual OCL2 spec OclAny represents any object except collections. However this is unaligned with UML2 and MOF2 where such kind of type does not exist Instead in MOF we have the generic Object which represents any object including primitive and collection values. Also, looking at the list of operations defined for OclAny we see that there is no real justification for creating this special type. Operations like 'allInstances' and 'oclIsNew' are also invalid for primitive types and hence are not specifically invalid for collections. Making OclAny to represent any object (equivalent to MOF::Object) will simplify the stdlib and will be consistent with UML2 and MOF2. Resolution: OclAny denotes now any object including collections. This makes the type system aligned with MOF. Revised Text: (1) In Section 8.2, AnyType, replace the actual AnyType definition: AnyType is a special type that complies to all the types except the collection types. AnyType has a unique instance named OclAny. It is defined to allow defining generic operations that can be invoked in any object or primitive literal value. By the following: AnyType is the metaclass of the special type OclAny, which is the type to which all other types conform.  OclAny is the sole instance of AnyType.  This metaclass allows defining the special property of being the generalization of all other Classifiers, including Classes, DataTypes and PrimitiveTypes. (2) In Section "8.2.1 Type Conformance", remove the second rule for Classifiers (All classifiers except collections conform to OclAny) (3) In Section "11.2.1 OclAny", replace the sentences "All types in the UML model and the primitive types in the OCL standard library complies with the type OclAny. Conceptually, OclAny behaves as a supertype for all the types except for the OCL pre-defined collection types." By "All types in the UML model and the primitive and collection types in the OCL standard library conforms to the type OclAny. Conceptually, OclAny behaves as a supertype for all the types." Actions taken: October 10, 2008: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== s is issue # 12948 Making OclAny denote any object Summary: In the actual OCL2 spec OclAny represents any object except collections. However this is unaligned with UML2 and MOF2 where such kind of type does not exist Instead in MOF we have the generic Object which represents any object including primitive and collection values. Also, looking at the list of operations defined for OclAny we see that there is no real justification for creating this special type. Operations like 'allInstances' and 'oclIsNew' are also invalid for primitive types and hence are not specifically invalid for collections. Making OclAny to represent any object (equivalent to MOF::Object) will simplify the stdlib and will be consistent with UML2 and MOF2. From: "Christian W. Damus" To: ocl2-rtf@omg.org Subject: Re: Additional resolution proposals Date: Sat, 18 Oct 2008 09:43:10 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: Hi, Mariano, Thanks for taking these issues on! I have a few general comments: The title page references "OCL 2.1 XMI files." Are there XMIs for the 2.0 version? They don't seem to be available on the OMG website The RTF membership list has Zeligsoft's member and organization names reversed On specific issues: >>> 12583 "OCL 2.0 8.2 Real" Agreed. >>> 12944 "Type of a type expression" Agreed. Let us ensure that the resolution of 9171 clearly indicates that the type of the Type Expression is not the referred type, as suggested by the issue's submitter, but the Classifier metaclass. >>> 12945 "Missing definition of iterators for OrderedSets" The definitions look good. However, the signatures of all but the select iterator are incomplete. The others should be indicated as: reject(expression : OclExpression) : OrderedSet(T) collectNested(expression : OclExpression) : Sequence(T) sortedBy(expression : OclExpression) : OrderedSet(T) >>> 12946 re: missing OrderedSet operations Agreed. >>> 12947 "Clarify the common supertype of Bag and Sequence" Agreed. Also, the resolution text has two occurrences of "sentence" that should be "sequence." >>> 12948 "Making OclAny denote any object" The phrase "that complies with all the types" does not make sense to describe the AnyType metaclass. It is OclAny that should be described as a type to which all other types conform. Perhaps we can replace the AnyType definition with: AnyType is the metaclass of the special type OclAny, which is the type to which all other types conform. OclAny is the sole instance of AnyType. A distinct metaclass is required to define the special property of being the generalization of all other Classifiers, including Classes, DataTypes, PrimitiveTypes. In the replacement text for (3) in Section 11.2.1, I think "conform to" is more consistent terminology than "comply with." >>> 12950 "No way to represent type parameters in the standard library" How are instances of the TemplateParameterType to be owned? I would expect a package such as the Standard Library to have multiple instances named "T" with different semantics indicated by the specification property. If that is the case, then it seems that they would need to have distinct owners. In the UML, parametered elements are generally owned by the classifiers or operations that expose them. I suppose that OCL can define a composite association on CollectionType for the type parameter T of its elementType, but for Operations (as imported from UML) it may be more difficult. We can define a composite end owned by the association that is nonetheless navigable, but I'm not sure that it works well with XMI ... >>> 12951 "Use of MOF reflection in EssentialOcl should be clarified" Agreed. It might be beneficial, also, to add a statement to the effect that reflection is provided by the oclIsKindOf(), oclIsTypeOf(), and oclType() operations (the latter upon adoption of the proposal for Issue 9171). >>> 12952 "Use of simple [sic] quotes and double quotes in strings" Agreed. We should make sure that Issue 8789 adequately deals with single quotes in string literals; I am not sure that the current proposal does (I shall endeavour to amend it). Cheers, Christian On 17-Oct-08, at 1:00 PM, wrote: -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAFnjkrUnw6T/2dsb2JhbADXHoIygWgF Date: Fri, 21 Aug 2009 17:25:48 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: ocl2-rtf@omg.org Subject: OCL 2.1 Issue 12948 'Making OclAny denote any object' disposition has very unfortunate corrolaries X-Plusnet-Relay: fdda03c9b0cedc1dc721fa35012c6cd0 Hi All The change to make Collection conform to OclAny is very welcome but unfortunately not all the corrolaries have been considered. OCL was conceived when a UML multiplicity of objects was not an object, and not all objects inherited from Object. OCL 2.0 therefore defines OclAny as the top object type and explicitly defines Collection as an incompatible family of non-objects whose type is derived from CollectionType and whose operations are defined for CollectionType. As non-objects, collections do not support the OclAny object navigation operator ".". Instead they support the non-object navigation operator "->". Since the "." operator was unused, it was re-used as an implicit-collect shorthand. [This is very confusing to naive and experienced OCL programmers.] Therefore when we ask the question: Is a Collection an object? we mean: Is the type of a collection OclAny. In Ocl 2.0 the answer was clearly no. In the Issue 12948 disposition for Ocl 2.1 the answer is clearly yes. This is a very significant semantic change. It means that all the OclAny methods are valid for collections and could/should be invoked in the same way. Therefore an OclAny method on a collection is invoked as: collection . operationDefinedForOclAny which is inconsistent with a Collection method which is invoked in OCL 2.0 as: collection -> operationDefinedForCollection This will be even more confusing to naive and experienced OCL programmers. While it is possible to define a clear distinction between collection . name as a) use of an OclAny or derived feature b) implicit collect of collection element feature that distinction is destined to be a source of major confusion to programmers who often cannot, and certainly should not need to, understand the language design problem that causes the programming problem. I see four possible solutions. a) Abandon the Issue 12948 change altogether - very disappointing since the change is well intentioned and much wanted I do not advocate this. b) Provide very careful well-formedness constraints and clarification to resolve the "." ambiguity between implicit collect and OclAny use. - I'm not entirely sure that such as a resolution is statically possible, particularly not without leaving OCL programs very vulnerable to silent semantic change through introduction of a meta-model feature that changes the resolution. I feel that this could make OCL a rather broken language. c) Can "." as implicit-collect be phased out? Unthinking OCL programmers have learnt to just swap "." and "->" until it works. In practice this demonstrates that there are relatively few expressions that are semantically correct for both operators. Therefore if "." implicit collect was retained for compatibility only, an OCL tool could be required to: A: resolve "." as a Collection Object navigation B: resolve "." as an implicit collect and offer the following modes of behaviour: In exclusive 2.1 mode: A is an Object navigation not A is an error In strict 2.1 mode: A and not B is an Object navigation A and B is an Object navigation with an error message B and not A is an implicit collect with a warning message In lazy 2.1 mode: A and not B is an Object navigation A and B is an Object navigation with a warning message B and not A is an implicit collect In lazy 2.0 mode: A and not B is an Object navigation A and B is an Object navigation with a warning message B and not A is an implicit collect In exclusive 2.0 mode: not B is an error B is an implicit collect The eror or warning message can be eliminated by explicit association-style qualification. If the above policy is acceptable, it could be appropriate to re-instate implicit collect using "->" This will of course give extra warnings. Swapping the semantics of "." and "->" for collections is a very fundamental change, which I would have considered unthinkable. Such a change certainly shouldn't be contemplated without a study of the practical impact on a significant body of code. Is the following usage able to convert rapidly? - use the 'strict 2.1' mode to identify all ambiguities as errors - manually eliminate all errors - use 'lazy 2.1' mode ignoring warnings - use an automatic converter to swap no longer ambiguous "." and "->". d) Defer resolution of Issue 12948 until a good solution to the "." ambiguity problem is available. ------------------------------ Conclusion: Giving Collections Object Oriented characteristics is good but there is a conflict with implicit collect. It may be possible to use some subtle wording to avoid these problems in a slightly revised OCL 2.1. However the conflict will remain as an increasing confusion for OCL programmers and as a major impediment to provision of future OCL specifications. Horrible as swapping "." and "->" for collections is, I think it is the least bad alternative. ----- Since Issue 12948 is perhaps the most important change to OCL 2.1 that hasn't already been adopted intuitively by vendors, I suggest that OCL 2.0 remain as the preferred version subject to the same ongoing vendor intuition. Without full examination of all the semantic consequences of this fundamental language change, OCL 2.1 risks introducing confusions that are difficult for OCL 2.3 to unwind. The OCL 2.3 RTF is already chartered and should consider an alternate solution, perhaps with the aid of usage trials. I favour migrating implicit-collect away from ".". Regards Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsHAP98lkrUnw4S/2dsb2JhbACCJTGXGb8vhBkF Date: Thu, 27 Aug 2009 20:38:29 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) To: "'ocl2-rtf@omg.org'" Subject: Re: OCL 2.1 Issue 12948 'Making OclAny denote any object' disposition has very unfortunate corrolaries X-Plusnet-Relay: e7dc79c7fd0c21124d65ef7ad1b900ca Hi I think there is a simple solution to preserving the existing semantics while allowing Collection to subtype OclAny/Classifier. In OCL 2.0 e.g. Collection::size() is a regular operation of a special irregular type. The proposed change for 2.1 makes it a regular operation of a regular type introducing nasty corrolaries for regular use. Therefore a new solution: e) Let Collection be a regular OclAny/Classifier type, but redesignate all Collection operations as special arrow-features. An arrow feature is a regular feature with a name spelled as e.g. "->size". This cannot conflict with current usage since no lexer can treat -> as part of a name. The 2.0 invocation of collection operations: source -> feature can be redefined as a shorthand for regular navigation of an arrow-feature. source . ->feature The special case of implicit conversion to Bag{}/Set{} is resolved by defining all the arrow-features on OclAny. e.g. OclAny::->size() = Collection{self}->size() -- = Collection{self} . ->size() this is overloaded for the true Collection::->size() method and for OclVoid::->size() = 0 no explicit overload is necessary for OclInvalid, since the Collection{self} is satisfactorily invalid. Practical implementations will no doubt realise: OclInvalid::->size() = invalid This eliminates implicit conversion to sets; replacing it by OclAny/Classifier overloads. This eliminates the invocation irregularity of collection operations without introducing a namespace conflict. If the special operations are consistently documented as e.g. ->forAll, users will rapidly learn that -> is just the prefix for built-in library functionality; no longer anything strange for collections. [oclIsNew could migrate to ->isNew]. [Potentially users can provide overloads for any special feature, although this requires a solution to specifying difficult names; already a problem for a >= overload.] This still leaves implicit collect to worry about. object.feature is the object method/invalid; no change collection.feature is the implicit collect/invalid; no change No ambiguity but confusing and a minor limitation. A user-defined operation such as Collection::depth() cannot be invoked, since collection.depth() is implicit collect. It is going to be necessary to introduce a special not-implicit-collect invocation syntax, or eliminate the current implicit collect syntax. Implicit collect makes it difficult for semantic validation to assist the OCL programmer or OCL reader to understand a collection. Many meta-models use singular names for collection properties, so manager.employee.name() is easily misunderstood. Abandoning the existing shorthand and perhaps replacing it by *. would ensure that manager.employee.name() was a syntax error requiring change to manager.employee*.name(), which alerts the reader to the plurality of the singular employee. The ideas above can achieve the intended OCL 2.1 semantic evolution without adverse consequences. If the OCL 2.1 proposal is adopted, it will be very difficult to find a compatible solution for both OCL 2.0 and the current 2.1 proposal. Regards Ed Willink Brucker, Achim wrote: Hi, Is a Collection an object? we mean: Is the type of a collection OclAny. In Ocl 2.0 the answer was clearly no. if I remember the situation correctly, the answer was "yes" in the very first versions of OCL (i.e., version 1.1) and (I think with OCL/UML 1.3) it was a deliberate decision to make the collections not a subtype of OclAny. Albeit, I do not recall the detailed reasoning behind this decision. In any case, one should take care that the combination of OclAny being a superclass of Collection, together with the automatic conversion and flattening operations does not result in an inconsistent set theory (i.e., one that allows for expressing Russell's paradox). d) Defer resolution of Issue 12948 until a good solution to the "." ambiguity problem is available. we need definitely clarify all parts of the language that are which points in the standard affected by this change. This seems to touch a critical area with a lot of subtitles. Thus I have a slight tendency to defer this issue.. Best regards, Achim From: "Brucker, Achim" To: "'Ed Willink'" , "'ocl2-rtf@omg.org'" Date: Thu, 27 Aug 2009 00:30:12 +0200 Subject: RE: OCL 2.1 Issue 12948 'Making OclAny denote any object' disposition has very unfortunate corrolaries Thread-Topic: OCL 2.1 Issue 12948 'Making OclAny denote any object' disposition has very unfortunate corrolaries Thread-Index: AcoifMMbC6gJL2pjQUuYV8JTRC+rrwEHnhuA Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE X-Scanner: Virus Scanner virwal07 X-SAP: out X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n7QMOKO1005480 Hi, > > Is a Collection an object? > > we mean: Is the type of a collection OclAny. > > In Ocl 2.0 the answer was clearly no. if I remember the situation correctly, the answer was "yes" in the very first versions of OCL (i.e., version 1.1) and (I think with OCL/UML 1.3) it was a deliberate decision to make the collections not a subtype of OclAny. Albeit, I do not recall the detailed reasoning behind this decision. In any case, one should take care that the combination of OclAny being a superclass of Collection, together with the automatic conversion and flattening operations does not result in an inconsistent set theory (i.e., one that allows for expressing Russell's paradox). > > d) Defer resolution of Issue 12948 until a good solution to the "." > ambiguity problem is available. we need definitely clarify all parts of the language that are which points in the standard affected by this change. This seems to touch a critical area with a lot of subtitles. Thus I have a slight tendency to defer this issue.. Best regards, Achim