Issue 13331: QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types (qvt-rtf) Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody) Nature: Uncategorized Issue Severity: Summary: As interpretation from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems: 1. The specification doesn't provide any name for these typedefs. 2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation. Solution for 1). Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type. Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias. Solution for 2). Suggestion a: Taking the typedef as the referenced type in QVTo transformations. Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations. Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced. It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference. My solution's preference in order are: c) Just having one type to refer. a) Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one. b) The OCL predefined type is referenced, but we must taking into account that operations added to the typedef are available. Resolution: issue closed, duplicate of issue # 13252 Revised Text: Actions taken: December 22, 2008: received issue January 26, 2009: issue closed, duplicate of issue # 13252 Discussion: End of Annotations:===== ender: Adolfo Sanchez Barbudo Date: Mon, 22 Dec 2008 17:24:39 +0000 From: Adolfo Sánchez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Juergen Boldt Subject: Re: issue 13181 -- MOF QVT RTF issue Ok Juergen!! Thank you very much !!! BTW, I have a new issue, just below. Cheers, Adolfo. ** QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types. ** As interpretation from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems: 1. The specification doesn't provide any name for these typedefs. 2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation. Solution for 1). Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type. Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias. Solution for 2). Suggestion a: Taking the typedef as the referenced type in QVTo transformations. Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations. Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced. It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference. My solution's preference in order are: c) Just having one type to refer. a) Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one. b) The OCL predefined type is referenced, but we must taking into account that operations added to the typedef are available. Juergen Boldt escribió: you can send them to qvt-rtf as well as issues@omg.org ( or to me directly) -Juergen At 08:15 AM 12/22/2008, you wrote: Ok. Another question. Should I better send the issues, via issues@omg.org or qvt-rtf@omg.org mail list? If I use the web page, the issues aren't well formatted... Again, I'm sorry for the inconvenience. The correct text is below. Issue 13181. Regards, Adolfo. Juergen Boldt escribió: Adolfo. just send me the updated tes=xt and I will replace in the issue's description ** QVTo Standard Library. Some operation's returned values would better return the TemplateParameterType ** Several stdlib operations would be better changed to avoid doing unnecessary castings on the returned value of the operation. For AnyType::oclAsType(oclType) operation I could write: var aClass : Class := anotherVar.oclAsType(Class); However, for Model::objectsOfType(OclType) operation I can't do: var aClassSet : Set(Class) := aModel.objectsOfType(Class); I have to do the following, instead: var aClassSet : Set(Class) := aModel.objectsOfType(Class).oclAsType(Set(Class)); Therefore, for end-user usability, I propose exploiting TemplateParameterType and changing some QVTo Standard Library operations Element::subobjectsOfType(OclType) : Set(T) Element::allSubobjects(OclType) : Set(T) Element::subobjectsOfKind(OclType) : Set(T) Element::allSubobjectsOfKind(OclType) : Set(T) Element::clone() : T Element::deepclone() : T Model::objectsOfType(OclType) : Set(T) Model::copy() : T Model::createEmptyModel(): T Note: this approach is made in the Object::asOrderedTuple() : OrderedTuple(T) operation. -Juergen At 04:47 AM 12/22/2008, you wrote: Hi all, I made a mistake using the browser, and some text is mixed with the text of the previous issue (13180), so that the last two sentences are misplaced from the previous one. I don't know if this can be fixed in somehow.... Sorry for the inconvenience. Cheers, Adolfo. Juergen Boldt escribió: From: webmaster@omg.org Date: 19 Dec 2008 13:55:07 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Adolfo Sanchez-Barbudo Herrera Company: Open Canarias S.L. mailFrom: adolfosbh@opencanarias.com Notification: Yes Specification: MOF 2.0 QVT Section: 8.3 FormalNumber: formal/2008-04-03 Version: 1.0 RevisionDate: 04/03/08 Page: 104 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Description ** QVTo Standard Library. Some operation's returned values would better return the TemplateParameterType ** Several stdlib operations would be better changed to avoid doing unnecessary castings on the returned value of the operation. While for AnyType::oclAsType(oclType) operation I could write: var aClass : Class := anotherVar.oclAsType(Class); for Model::obectsOfType(OclType) operation I can't do: var aClassSet : Set(Class) := aModel.objectsOfType(Class); I have to do the following instead: var aClassSet : Set(Class) := aModel.objectsOfType(Class).oclAsType(Set(Class)); Therefore, for end-user usability, I propose exploiting TemplateParameterType and changing some QVTo standard Library operations Element::subobjectsOfType(OclType) : Set(T) Element::allSubobjects(OclType) : Set(T) Element::subobjectsOfKind(OclType) : Set(T) Element::allSubobjectsOfKind(OclType) : Set(T) Element::clone() : T Element::deepclone() : T Model::objectsOfType(OclType) : Set(T) Model::copy() : T Model::createEmptyModel(): T Note: this approach is made in the Object::asOrderedTuple() : OrderedTuple(T) operation. same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Adolfo Sánchez-Barbudo Herrera adolfosbh@opencanarias.com C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 / +34 617 718268 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Adolfo Sánchez-Barbudo Herrera adolfosbh@opencanarias.com C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 / +34 617 718268 -------------------------------------------------------------------------------- Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Adolfo Sánchez-Barbudo Herrera adolfosbh@opencanarias.com C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 / +34 617 718268