Issue 12945: Missing definition of of iterators for OrderedSets (ocl2-rtf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com) Nature: Uncategorized Issue Severity: Summary: Summary:Since the iterators are redefined for each concrete collection type We would expect a "11.9.5 OrderedSet" section. Moreover, when defining nestedCollect for OrderedSet we should expect the type to be a Sequence (in constrast to Set::nestedCollect which type is a Bag). Resolution: The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets. Revised Text: The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets. Revised Text: Add a new section "11.9.5 OrderedSet" with the following content: The standard iterator expressions with source of type OrderedSet(T) are: select (expression : OclExpression) : OrderedSet(T) The ordered set of the source ordered set for which body is true. source->select(iterator | body) = source->iterate(iterator; result : OrderedSet(T) = OrderedSet{} | if body then result->including(iterator) else result endif) select may have at most one iterator variable. reject (expression : OclExpression) : OrderedSet(T) The ordered set of the source ordered set for which body is false. source->reject(iterator | body) = source->select(iterator | not body) reject may have at most one iterator variable. collectNested (expression : OclExpression) : Sequence(T) The sequence of elements that results from applying body to every member of the source ordered set. source->collectNested(iterators | body) = source->iterate(iterators; result : Sequence(body.type) = Sequence{} | result->append(body ) ) collectNested may have at most one iterator variable. sortedBy (expression : OclExpression) : OrderedSet(T) Results in the ordered set containing all elements of the source collection. The element for which body has the lowest value comes first, and so on. The type of the body expression must have the < operation defined. The < operation must return a Boolean value and must be transitive (i.e., if a < b and b < c then a < c). source->sortedBy(iterator | body) = iterate( iterator ; result : OrderedSet(T) : OrderedSet {} | if result->isEmpty() then result.append(iterator) else let position : Integer = result->indexOf ( result->select (item | body (item) > body (iterator)) ->first() ) in result.insertAt(position, iterator) endif sortedBy may have at most one iterator variable Actions taken: October 10, 2008: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== s is issue # 12945 Missing definition of of iterators for OrderedSets Summary:Since the iterators are redefined for each concrete collection type We would expect a "11.9.5 OrderedSet" section. Moreover, when defining nestedCollect for OrderedSet we should expect the type 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 to be a Sequence (in constrast to Set::nestedCollect which type is a Bag).