Issue 7755: factory create_<component_name> (); Unconsistent association extension description (mof2idl-ftf) Source: Vanderbilt University (Mr. Jeff Parsons, j.parsons@vanderbilt.edu) Nature: Uncategorized Issue Severity: Summary: The first factory operation described for homes factory create_<component_name> (); has the same signature as the create() method generated from the 'implied IDL' *HomeImplicit interface. The implied IDL *Home interface inherits from *HomeImplicit, so it seems we already have an operation in the equivalent home interface that is doing the same thing as the declared factory operation. Resolution: Revised Text: Resolution: This is a duplicate of issue 7682 See issue #7682 Actions taken: August 31, 2004: received issue August 1, 2005: closed issue Discussion: End of Annotations:===== ubject: RE: More mapping questions Date: Tue, 31 Aug 2004 14:49:55 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More mapping questions Thread-Index: AcSMWaVVVV305u3vRcOFApCKD+E50AC2horQABe0OWA= From: "Jeff Parsons" To: "Michael Soden" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7VK4D1U022300 Hi, I forgot one question I was going to put in the previous email: The first factory operation described for homes factory create_ (); has the same signature as the create() method generated from the 'implied IDL' *HomeImplicit interface. The implied IDL *Home interface inherits from *HomeImplicit, so it seems we already have an operation in the equivalent home interface that is doing the same thing as the declared factory operation. thanks, Jeff > -----Original Message----- > From: Michael Soden [mailto:soden@fokus.fraunhofer.de] > Sent: Tuesday, August 31, 2004 4:57 AM > To: Jeff Parsons > Cc: mof2idl-ftf@omg.org > Subject: RE: More mapping questions > > > Hi Jeff, > > here are a few answers to your questions. You should also > raise them formally at the OMG's issue list. > > > Rule (26) p. 21 > > > > Although I see the member types for the *Link struct specified, I > > don't see anything about the member names. Are they specified > > somewhere else? How are they to be derived? > > At this point, we referred to the MOF1.4, by saying "As in > MOF1.4 [...]" (a bit too short and in the wrong sentence I > guess). For that reason, the IDL struct should contain > members with names in "format_2". > > > > > Rule (27) p. 21 > > > > Same as above, for members of the valuetype *State, > > mapped from an Association. > > > > Correct, the identifier is missing. I propose to use > "links_of_" concatenated with the associations' identifier > (in format_2). > > > Section 7.6.3 pp. 59,60 > > > > With regard to the operations 'create_link_in_' > > and 'remove_link', the Exception paragraphs contain > information only > > about the case where association ends are defined as > derived unions. > > It's not clear what the behavior is otherwise. > > > > Right, the default case is missing. We assumed that the > operations raise the MofError exception in any other case. > > > Section 7.4 pp. 49,50 > > > > The type of MofError::error_kind and MofERror::error_description > > (section 6.2.10 p. 20 & section 7.4 p. 50) are both > wstring, but there > > is also a list of IDL string constants (section 7.4 p. 49). How are > > the constants to be used? Are they to be passed as one of > MofError's > > wstring members? If so, how come the type mismatch? > > I recognized that this is a "copy and paste error" from the > MOF1.4 spec, which includes exactly the same mismatch. I > propose to change the constant definitions' type to > "wstring". However, I guess we need to spend some effort on > the exception framework. I found a few more places where our > spec is imprecise. > > > > > Rule (38) p. 30 > > > > The CCM component mapping for an Association has the suffix > > "Component", unlike any of the the other component mappings in the > > document. That's a little puzzling. Also, no details are > given about > > the corresponding home mapping. How is its type name > derived? Does it > > have the same factory operations as the other CCM home > mappings in the > > document? > > > > As the example on page 31 shows, the component is managed by > a home interface named according to the assocation-name with > the postfix "Home". But you are right: the corresponding rule > to produce that interface is missing. Basically, the home > interface is only needed if we have to navigate from a > package to its contents (cp. Rules 40/41 on page 33). IMHO, > we should change the spec to be able to directly navigate to > an association's derived component. Since the lifecycle of > the component is determined by the outermost package's > component (implicit creation) we need no factory operations > and therefore in principle no home interface. That results > from the fact that the components derived for an association > are rather the M2-level "representative" (in the repository) > than a M1-level instance. I think we need to consistently > adjust the spec regarding this issue. > > What is your opinion on this topic?? > > Regards, > Michael > > From: "Michael Soden" To: "'Jeff Parsons'" Cc: Subject: Other questions Date: Thu, 2 Sep 2004 17:35:59 +0200 Organization: Fraunhofer FOKUS X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSMWaVVVV305u3vRcOFApCKD+E50AC2horQABOm9gAAX0UWcA== Hi Jeff, here are a few more answers to your other questions (I've copied all your issues into this mail and I hope I haven't forgot something). > > There has been some discussion among folks involved with the > Lightweight CCM spec about doing away with homes (and CIDL), > and we have thought about providing it as an alternative option > in our implementation. It certainly seems doable. > > However, having some components in a set of IDL files with homes > and some without would add complexity to the CIDL compiler and > to the implementation. Or have I misunderstood what you are > proposing? > Correct, you got the point. I think we should use "Homes" only if we need factory operations (i.e. for outermost packages, classes, etc.) and finder operations. I know, that the spec currently derives more home interfaces than actually needed, but maybe it's worth a discussion to eliminate those that are not needed. For example, if a package is nested in another package, the inner package's lifecycle is bounded to the outermost one's anyway. Since packages in general are only used for the definition of a clear "model boundary" at the M1 or let's say, directory structure for managing an metamodel's instances, I think we need only one home for the outermost package. Then it's up to this component to create all nested ones derived for inner packages. But in principle I would assume no additional complexity for your CIDL compiler. What do you think? >The first factory operation described for homes > >factory create_ (); > >has the same signature as the create() method generated from the 'implied >IDL' *HomeImplicit interface. The implied IDL *Home interface inherits from >*HomeImplicit, so it seems we already have an operation in the equivalent >home interface that is doing the same thing as the declared factory >operation. Well, I had a look into the CCM spec and right: the create operation is conflicting with the *HomeImplicit interface. When writing the spec, we assumed that this operation is only generated per default if the home interface is emtpy (comparable to the default constructor in Java). However, we need to fix this. Hope I haven't forgot anything, Sincerely, >