Issue 7866: inadequate definition of 'constructor' (uml2-superstructure-ftf) Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The current "definition" of constructor, section 9.3.1 "Notation" subsection (page 75) leaves some issues. The description proposes a notation for associating an instance representation with a "constructor", noting only that a constructor is an operation that "must have the class as its classifier." Given a list of operations (_ _ is static): _+ newInstance(name:String):Foo_ _+ getFooForName(name:String):Foo_ + identity():Foo + clone():Foo + Foo(name:String):Foo _+ Foo(name:String):Foo_ _+ make(name:String):Foo_ Any of the above operations could be viewed as a constructor under the definition provided. The only marker suggested in the superstructure specification to clearly specify a constructor is a "<<create>>" assocation from the default instance created by the constructor. Assuming foo:Foo: Foo::newInstance("bar") foo.clone() Foo::make("bar") Foo::Foo("bar") In the predominant commercial OO languages, newInstance(...) and clone() are delegating the actual creation to Foo::Foo(...), but clone or copy may be the vehicles of instantiation in languages like io or self. If UML had a specific marker for constructors, like the stereotype "<<constructor>>" then OCL and other notations and tools could treat constructors specially where useful. The OCL specificaion already includes notation for Tuple and Collection "constructors" to specify what are essentially Tuple and Collection constants. Providing a standard marker for constructors might reliably allow similar clear constructs for all other types (ex. if baz > Foo(1.30, Currency::USDollars) then ...). Resolution: Revised Text: Actions taken: October 17, 2004: received issue Discussion: End of Annotations:===== ubject: FW: inadequate definition of 'constructor' Date: Sun, 17 Oct 2004 06:56:04 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: inadequate definition of 'constructor' Thread-Index: AcSz83KhqtaY9f3CRW+RWUS0zD95pwAXWZvA From: "Karl Frank" To: "Juergen Boldt" , Cc: "Dan Massey" X-OriginalArrivalTime: 17 Oct 2004 13:56:20.0407 (UTC) FILETIME=[1497F470:01C4B451] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i9HEHY1U013996 Juergen, hi. My friend Dan Massey sent this issue to you and his email bounced for reasons unknown, so I am relaying it to you. - Karl Frank -----Original Message----- From: Dan Massey [mailto:dan@danmassey.com] Sent: Saturday, October 16, 2004 10:46 PM To: issues@omg.org Cc: Juergen@OMG.ORG Subject: inadequate definition of 'constructor' Issue against: UML 2 Superstructure, finalized version ptc/041005 Issue title: inadequate definition of 'constructor' Description: The current "definition" of constructor, section 9.3.1 "Notation" subsection (page 75) leaves some issues. The description proposes a notation for associating an instance representation with a "constructor", noting only that a constructor is an operation that "must have the class as its classifier." Given a list of operations (_ _ is static): _+ newInstance(name:String):Foo_ _+ getFooForName(name:String):Foo_ + identity():Foo + clone():Foo + Foo(name:String):Foo _+ Foo(name:String):Foo_ _+ make(name:String):Foo_ Any of the above operations could be viewed as a constructor under the definition provided. The only marker suggested in the superstructure specification to clearly specify a constructor is a "<>" assocation from the default instance created by the constructor. Assuming foo:Foo: Foo::newInstance("bar") foo.clone() Foo::make("bar") Foo::Foo("bar") In the predominant commercial OO languages, newInstance(...) and clone() are delegating the actual creation to Foo::Foo(...), but clone or copy may be the vehicles of instantiation in languages like io or self. If UML had a specific marker for constructors, like the stereotype "<>" then OCL and other notations and tools could treat constructors specially where useful. The OCL specificaion already includes notation for Tuple and Collection "constructors" to specify what are essentially Tuple and Collection constants. Providing a standard marker for constructors might reliably allow similar clear constructs for all other types (ex. if baz > Foo(1.30, Currency::USDollars) then ...).