Issue 2314: Supporting multiple abstract interfaces (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Valuetypes should be able to support multiple abstract interfaces but only a single regular interface. See also comments number 28 and 31 in the list of core 2.3a errata I just sent out. Resolution: Incorporate changes in 2.4 and close issue. Revised Text: Resolution: Make changes to allow valutypes to support multiple abstract interfaces. The current prohibition on valuetypes supporting multiple interfaces was intended to prevent the OBV spec introducing multiple interface support by the "back door." The argument went that there is not much if any difference between a valuetype supporting multiple IDL interfaces and any implementation supporting sulitple IDL interfaces. Since we had no standard way to do the latter, we should not invent a standard way to do the former but not the latter, and we should not invent a standard way to do the latter as part of adding OBV. All very logical and reasonable. This consideration does not require disallowing support of multiple abstract interfaces. These are just giving the valuetype additional type semantics, as in C++ where a class has multiple abstract base classes containing only pure virtual functions, or in Java where a class implements multiple Java (not IDL) interfaces. So there is no reason to prevent this. The reason to allow this is the Java to IDL mapping. A Java serializable class that implements multiple RMI abstract interfaces (i.e., interfaces that do not extend java.rmi.Remote but whose methods throw RemoteException) is mapped to an IDL valuetype that supports multiple IDL abstract interfaces. If the latter is prohibited, we cannot correctly support the former. Revised Text: a. Page 3.13, section 3.4, production 19. Change last line to [ "supports" <interface_name> { "," <abstract_interface_name> }* ] b. Page 3.13, section 3.4, add new production <abstract_interface_name> ::= <scoped_name> c. Make above two changes in section 3.8.1.3 on page 3-23. d. Page 3-24, section 3.8.1.3, first line. Change "and <interface_name>" to "<interface name>, and <abstract_interface_name>". e. Page 3-27, section 3.8.5, third paragraph, add "and any number of abstract interfaces" at end of sentence. f. Page 3-27, section 3.8.5, third line of fifth paragraph. Change "interfaces and abstract interface" to "interface and abstract interfaces". g. Page 3-27, table 3-10. Add new column for Abstract Interface following the column for Interface. Contents are the same as the existing column for Interface except that the entry for Stateful Value should be "supports". h. Page 3-27, table 3-10. Abstract Value inherits from Interface should be "supports single". Also add new row for Abstract Interface, with contents (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) no multiple no no no i. Page 6-2, add new numbered point 6 before existing point 6 (which becomes point 7): Value types may support any number of abstract interfaces, but no more than one regular interface. j. Page 10-16: Change the supported_interface parameter of the create_value method of Container to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-58. k. Page 10-19: Change supported_interface to supported_interfaces. l. Page 10-34: Change the supported_interface attribute of ValueDef to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-64. m. Page 10-35: Change the supported_interface member of ValueDescription to a member named supported_interfaces with a data type of RepositoryIdSeq. Also make this change on page 10-66. n. Page 10-36: Change the first paragraph of section 10.5.24.1 to "The supported_interfaces attribute lists the interfaces that this value type supports." o. Page 10-36: In section 10.5.24.2, change supported_interface to supported_interfaces. Actions taken: January 20, 1999: received issue September 16, 1999: closed issue Discussion: a. Page 3.13, section 3.4, production 19. Change last line to End of Annotations:===== Date: Wed, 20 Jan 1999 19:35:07 +0000 From: Simon Nash Organization: IBM To: issues@omg.org CC: orb_revision@omg.org Subject: Supporting multiple abstract interfaces Valuetypes should be able to support multiple abstract interfaces but only a single regular interface. See also comments number 28 and 31 in the list of core 2.3a errata I just sent out. The updates required to the core chapters for this change are: a. Page 3.13, section 3.4, production 19. Change last line to [ "supports" { "," }* ] b. Page 3.13, section 3.4, add new production ::= c. Make above two changes in section 3.8.1.3 on page 3-23. d. Page 3-24, section 3.8.1.3, first line. Change "and " to ", and ". e. Page 3-27, section 3.8.5, third paragraph, add "and any number of abstract interfaces" at end of sentence. f. Page 3-27, table 3-10. Stateful Value inherits from Interface should be "supports" or else there should be a new column for Abstract Interface which should say "supports" and Interface should say "supports single". Also, Abstract Value inherits from Interface should be consistent with Stateful Value inherits from Interface. I would vote for an extra row and column for Abstract Interface as I think it's clearer. g. Page 6-2, add new numbered point 6: Value types may support any number of abstract interfaces, but no more than one regular interface. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Date: Fri, 22 Jan 1999 15:31:51 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: juergen@omg.org Subject: Issue 2314 Please add the following to the archive related to this issue: Page 3-27, section 3.8.5, third line of fifth paragraph. Change "interfaces and abstract interface" to "interface and abstract interfaces". See issue 1 above. Page 3-27, table 3-10. Abstract Value inherits from Interface should be "supports". (or add a new Abatract Interface row and column). Either way, they should be consistent. I would vote for the extra row and column as I think it's clearer. These are the alleged item 28 and 31 alluded to by Simon. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 01 Feb 1999 19:23:50 -0500 From: Paul H Kyzivat Organization: NobleNet To: Simon Nash CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 2 References: <36B2217E.6955B5EC@fpk.hp.com> <36B5CBD9.9393CAA8@noblenet.com> <36B5E7E1.2256AB70@hursley.ibm.com> Simon Nash wrote: > Paul H Kyzivat wrote: > > > > Jishnu - > > > > NobleNet votes as follows: > > > > NO on Issue 2314 (Supporting multiple abstract interfaces): > > Editing instructions g & h are ambiguous, so I don't know > > what I am voting on. > > > Fair enough, and to fix this I would like to propose as a friendly > amendment to my own motion the following changes to g & h: > > g. Page 3-27, table 3-10. Add new column for Abstract Interface > following the column for Interface. Contents are the same as > the existing column for Interface except that the entry for > Stateful Value should be "supports". > h. Page 3-27, table 3-10. Abstract Value inherits from Interface > should be "supports single". Also add new row for Abstract > Interface, > with contents > (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) > no multiple no no no > > > Also, instruction i can't be correct because > > there is already a point 6 in the text. > > > Instruction i is correct. The new point 6 should be inserted before > the existing point 6, which would become point 7. Assuming the above clarifications are made, NobleNet votes YES on 2314. > > NO on Issue 2322 (No description for NativeDef): > > The revised text still doesn't describe the read and write > > interfaces. I *think* the instructions should be similar to those > > for issue 2325. > > > There is no write interface, and the instructions are not the same > as > issue 2325 because NativeDef has no original_type_def attribute. > I took this wording from existing sections 10.5.14, 10.5.15, > 10.5.16, > and 10.5.17. Consistency with the style of the existing > specification > was my goal for this change, and I did not see any existing section > with only a "Read Interface" but no "Write Interface" subheading. OK. NobleNet votes YES on 2322. From: Jeffrey Mischkinsky Subject: Core RTF 2.4 Vote 2 - votes and 2 problems with solutions To: jis@fpk.hp.com (Jishnu Mukerji) Date: Wed, 3 Feb 1999 17:45:39 -0800 (PST) Cc: orb_revision@omg.org Inprise votes YES with the following exceptions: 2314, 2327, 1893 for which we abstain for the moment for the following reasons. If we've got it wrong, don't hesitate (not that any of you would :-) to correct the errors in our understanding. Issue 2314 and Issue 2327 appear to conflict with each other: 2314 allows a valuetype to support multiple abstract interfaces 2327 fixes the IR to take into account the decision to only allow a valuetype to support one interface, by changing the sequence of rep ids to a single rep id (supported interfaces -> supported interface) I'm not sure off hand how we would want to fix this. Issue 1893 says, among other things, that the scope of a union begins immediately following its opening "{". However a union has some "stuff" before its initial "{", namely a "(" is an , the identifier for the enumeration is in the scope of the union; ... This could easily be fixed by adding, in 1893, that the scope of a union begins immediately following the initial "(" jeff 'Jishnu Mukerji' writes: > > Core RTF Vote 2 is posted at the URL: > > http://www.omg.org/pub/orbrev/votes/2_4vote2.html > > The most current list of open Core RTF issues including their > current > status can be seen at the URL: > > http://www.omg.org/pub/orbrev/drafts/orb_revision_2_4.html > > Regards, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Date: Thu, 04 Feb 1999 01:16:49 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard New Jersey Laboratories To: Jeffrey Mischkinsky CC: orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 2 - votes and 2 problems with solutions References: <199902040145.RAA10857@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > Inprise votes YES with the following exceptions: > 2314, 2327, 1893 for which we abstain for the moment for the > following > reasons. If we've got it wrong, don't hesitate (not that any of > you would :-) > to correct the errors in our understanding. > > Issue 2314 and Issue 2327 appear to conflict with each other: > 2314 allows a valuetype to support multiple abstract interfaces > 2327 fixes the IR to take into account the decision to only allow > a > valuetype to support one interface, by changing the sequence > of > rep ids to a single rep id (supported interfaces -> supported > interface) > > I'm not sure off hand how we would want to fix this. Simon? Any thoughts? > Issue 1893 says, among other things, that the scope of a union begins > immediately following its opening "{". However a union has some "stuff" > before its initial "{", namely a "(" in the para following table 3-12 says that if the is an > , the identifier for the enumeration is in the scope of the union; > ... > This could easily be fixed by adding, in 1893, that the scope of a union > begins immediately following the initial "(" > Good point. I suggest that we put 1893 to vote again with the suggested additional sentence in the next vote, notwithstanding what happens in this vote. I plan to do this unless I hear any reasonable objections to taking this course of action. Thanks, Jishnu. Date: Thu, 04 Feb 1999 19:49:32 +0000 From: Simon Nash Organization: IBM To: Jeffrey Mischkinsky CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 2 - votes and 2 problems with solutions References: <199902040145.RAA10857@wheel.dcn.davis.ca.us> Jeff, Jeffrey Mischkinsky wrote: > > Inprise votes YES with the following exceptions: > 2314, 2327, 1893 for which we abstain for the moment for the > following > reasons. If we've got it wrong, don't hesitate (not that any of > you would :-) > to correct the errors in our understanding. > > Issue 2314 and Issue 2327 appear to conflict with each other: > 2314 allows a valuetype to support multiple abstract interfaces > 2327 fixes the IR to take into account the decision to only allow > a > valuetype to support one interface, by changing the sequence > of > rep ids to a single rep id (supported interfaces -> supported > interface) > > I'm not sure off hand how we would want to fix this. > Good catch. I suggest we resolve this by withdrawing both 2314 and 2327 from this vote. I will put a new proposal into the next vote > that includes the following: 1. Make all the changes currently proposed for 2314 2. Do not make the currently proposed changes for 2327 3. Change the supported_interface parameter of the create_value method of Container, the supported_interface attribute of ValueDef, and the supported_interface member of ValueDescription to all be named supported_interfaces with data types of InterfaceDefSeq (first two) and RepositoryIdSeq (last). Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 05 Feb 1999 12:19:01 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Simon Nash CC: Jeffrey Mischkinsky , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 2 - votes and 2 problems with solutions References: <199902040145.RAA10857@wheel.dcn.davis.ca.us> <36B9F9CC.C22A8902@hursley.ibm.com> So it looks like we will place modified resolutions for 2314 and 2327 up for vote in the next round. Y'all have until Wednesday 10 Feb 99 to send me propposed resolutions for inclusion in the 12 Feb vote. Thanks, Jishnu. Sender: jis@fpk.hp.com Date: Thu, 11 Feb 1999 18:18:36 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: orb_revision@omg.org Subject: Issue 2314 - multiple abstract interfaces I am getting a sense that 2314 needs further discussion. So let me initiate the discussion by placing the latest proposed resolution in front of everyone, without any comments of my own, instead of putting it up for a vote. I'd rather have a generally agreed upon proposed resolution (or two) to vote on instead of using the voting process as the means for arriving at an agreement. So please see attached and please decide whether this resoltuions works for you. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Issue 2314: Supporting multiple abstract interfaces (orb_revision) Click here for this issue's archive. Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com) Nature: Uncategorized Issue Severity: Summary: Valuetypes should be able to support multiple abstract interfaces but only a single regular interface. See also comments number 28 and 31 in the list of core 2.3a errata I just sent out. Resolution: Make changes to allow valutypes to support multiple abstract interfaces. Revised Text: a. Page 3.13, section 3.4, production 19. Change last line to [ "supports" { "," }* ] b. Page 3.13, section 3.4, add new production ::= c. Make above two changes in section 3.8.1.3 on page 3-23. d. Page 3-24, section 3.8.1.3, first line. Change "and " to ", and ". e. Page 3-27, section 3.8.5, third paragraph, add "and any number of abstract interfaces" at end of sentence. f. Page 3-27, section 3.8.5, third line of fifth paragraph. Change "interfaces and abstract interface" to "interface and abstract interfaces". g. Page 3-27, table 3-10. Add new column for Abstract Interface following the column for Interface. Contents are the same as the existing column for Interface except that the entry for Stateful Value should be "supports". h. Page 3-27, table 3-10. Abstract Value inherits from Interface should be "supports single". Also add new row for Abstract Interface, with contents (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) no multiple no no no i. Page 6-2, add new numbered point 6 before existing point 6 (which becomes point 7): Value types may support any number of abstract interfaces, but no more than one regular interface. j. Page 10-16: Change the supported_interface parameter of the create_value method of Container to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-58. k. Page 10-19: Change supported_interface to supported_interfaces. l. Page 10-34: Change the supported_interface attribute of ValueDef to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-64. m. Page 10-35: Change the supported_interface member of ValueDescription to a member named supported_interfaces with a data type of RepositoryIdSeq. Also make this change on page 10-66. n. Page 10-36: Change the first paragraph of section 10.5.24.1 to "The supported_interfaces attribute lists the interfaces that this value type supports." o. Page 10-36: In section 10.5.24.2, change supported_interface to supported_interfaces. Actions taken: January 20, 1999: received issue Date: Fri, 12 Feb 1999 21:30:50 +0000 From: Simon Nash Organization: IBM To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 2314 - multiple abstract interfaces References: <36C3654C.F92BDFE0@fpk.hp.com> Jishnu, I guess it's up to me as proposer of this motion to start the ball rolling. The current prohibition on valuetypes supporting multiple interfaces was intended to prevent the OBV spec introducing multiple interface support by the "back door." The argument went that there is not much if any difference between a valuetype supporting multiple IDL interfaces and any implementation supporting sulitple IDL interfaces. Since we had no standard way to do the latter, we should not invent a standard way to do the former but not the latter, and we should not invent a standard way to do the latter as part of adding OBV. All very logical and reasonable. This consideration does not require disallowing support of multiple abstract interfaces. These are just giving the valuetype additional type semantics, as in C++ where a class has multiple abstract base classes containing only pure virtual functions, or in Java where a class implements multiple Java (not IDL) interfaces. So there is no reason to prevent this. The reason to allow this is the Java to IDL mapping. A Java serializable class that implements multiple RMI abstract interfaces (i.e., interfaces that do not extend java.rmi.Remote but whose methods throw RemoteException) is mapped to an IDL valuetype that supports multiple IDL abstract interfaces. If the latter is prohibited, we cannot correctly support the former. Simon Jishnu Mukerji wrote: > > I am getting a sense that 2314 needs further discussion. So let me > initiate the discussion by placing the latest proposed resolution in > front of everyone, without any comments of my own, instead of > putting it > up for a vote. I'd rather have a generally agreed upon proposed > resolution (or two) to vote on instead of using the voting process > as > the means for arriving at an agreement. > > So please see attached and please decide whether this resoltuions > works > for you. > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > Issue 2314: Supporting multiple abstract interfaces (orb_revision) > > Click here for this issue's archive. > Source: International Business Machines (Mr. Simon C. Nash, > nash@hursley.ibm.com) > Nature: Uncategorized Issue > Severity: > Summary: Valuetypes should be able to support multiple abstract > interfaces but only a single regular > interface. See also comments number 28 and 31 in the list of core > 2.3a > errata I just sent out. > Resolution: Make changes to allow valutypes to support multiple > abstract > interfaces. > Revised Text: > a. Page 3.13, section 3.4, production 19. Change last line to > [ "supports" { "," }* > ] > b. Page 3.13, section 3.4, add new production > ::= > c. Make above two changes in section 3.8.1.3 on page 3-23. > d. Page 3-24, section 3.8.1.3, first line. Change "and > " > to ", and ". > e. Page 3-27, section 3.8.5, third paragraph, add "and any number of > abstract interfaces" at end of sentence. > f. Page 3-27, section 3.8.5, third line of fifth paragraph. Change > "interfaces and abstract interface" to "interface and abstract > interfaces". > g. Page 3-27, table 3-10. Add new column for Abstract Interface > following the column for Interface. Contents are the same as > the existing column for Interface except that the entry for > Stateful Value should be "supports". > h. Page 3-27, table 3-10. Abstract Value inherits from Interface > should be "supports single". Also add new row for Abstract > Interface, > with contents > (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) > no multiple no no no > i. Page 6-2, add new numbered point 6 before existing point 6 (which > becomes point 7): Value types may support any number of abstract > interfaces, but no more than one regular interface. > j. Page 10-16: Change the supported_interface parameter of the > create_value method of Container to a parameter named > supported_interfaces with a data type of InterfaceDefSeq. > Also make this change on page 10-58. > k. Page 10-19: Change supported_interface to supported_interfaces. > l. Page 10-34: Change the supported_interface attribute of ValueDef > to a parameter named supported_interfaces with a data type of > InterfaceDefSeq. Also make this change on page 10-64. > m. Page 10-35: Change the supported_interface member of > ValueDescription > to a member named supported_interfaces with a data type of > RepositoryIdSeq. Also make this change on page 10-66. > n. Page 10-36: Change the first paragraph of section 10.5.24.1 to > "The supported_interfaces attribute lists the interfaces that > this > value type supports." > o. Page 10-36: In section 10.5.24.2, change supported_interface to > supported_interfaces. > > Actions taken: > January 20, 1999: received issue -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Subject: Re: Issue 2314 - multiple abstract interfaces To: nash@hursley.ibm.com (Simon Nash) Date: Fri, 12 Feb 1999 21:31:02 -0800 (PST) Cc: jis@fpk.hp.com, orb_revision@omg.org 'Simon Nash' writes: > > Jishnu, > I guess it's up to me as proposer of this motion to start the ball > rolling. > > The current prohibition on valuetypes supporting multiple interfaces > was intended to prevent the OBV spec introducing multiple interface > support by the "back door." The argument went that there is not > much if any difference between a valuetype supporting multiple IDL > interfaces and any implementation supporting sulitple IDL > interfaces. > Since we had no standard way to do the latter, we should not invent > a standard way to do the former but not the latter, and we should > not invent a standard way to do the latter as part of adding OBV. > All very logical and reasonable. Simon, I thought the reason we disallowed it was because it was essentially impossible to generate legal code which combined the implementations of each interface into one implementation, because of the way the class hierarchies work. In that sense it was sort of introducing multiple interface support. But it was not the fact of the pseudo interface support that caused us to disallow it. The net result was that we had to create a "hidden" interface which multiply inherited from all the supported interfaces (i.e. combined them all into one interface) so that we were back to the single supports case. Except we had to figure out a mangled name for the "combination interface" which didn't conflict, and it turns out that it's not so hidden. Since it is in fact the class that the programmer has to use in her code. Hence, we decided allowing it wouldn't save us anything and in fact would complicate (and confuse) the user's life. When we talked about this issue internally we couldn't see why this logic also wouldn't apply to abstract interfaces? Since they could in fact be real interfaces. At some point the implementor has to provide a concrete implementation which will either be a valuetype or an interface. So stubs/skeletons have to be able to be generated. What do you think? jeff > > This consideration does not require disallowing support of multiple > abstract interfaces. These are just giving the valuetype additional > type semantics, as in C++ where a class has multiple abstract base > classes containing only pure virtual functions, or in Java where a > class implements multiple Java (not IDL) interfaces. > > So there is no reason to prevent this. The reason to allow this is > the Java to IDL mapping. A Java serializable class that implements > multiple RMI abstract interfaces (i.e., interfaces that do not > extend > java.rmi.Remote but whose methods throw RemoteException) is mapped > to an IDL valuetype that supports multiple IDL abstract interfaces. > If the latter is prohibited, we cannot correctly support the former. > > Simon > > Jishnu Mukerji wrote: > > > > I am getting a sense that 2314 needs further discussion. So let me > > initiate the discussion by placing the latest proposed resolution > in > > front of everyone, without any comments of my own, instead of > putting it > > up for a vote. I'd rather have a generally agreed upon proposed > > resolution (or two) to vote on instead of using the voting process > as > > the means for arriving at an agreement. > > > > So please see attached and please decide whether this resoltuions > works > > for you. > > > > -- > > Jishnu Mukerji > > Systems Architect > > > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > > > Issue 2314: Supporting multiple abstract interfaces (orb_revision) > > > > Click here for this issue's archive. > > Source: International Business Machines (Mr. Simon C. Nash, > > nash@hursley.ibm.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: Valuetypes should be able to support multiple abstract > > interfaces but only a single regular > > interface. See also comments number 28 and 31 in the list of core > 2.3a > > errata I just sent out. > > Resolution: Make changes to allow valutypes to support multiple > abstract > > interfaces. > > Revised Text: > > a. Page 3.13, section 3.4, production 19. Change last line to > > [ "supports" { "," > }* ] > > b. Page 3.13, section 3.4, add new production > > ::= > > c. Make above two changes in section 3.8.1.3 on page 3-23. > > d. Page 3-24, section 3.8.1.3, first line. Change "and > > " > > to ", and ". > > e. Page 3-27, section 3.8.5, third paragraph, add "and any number > of > > abstract interfaces" at end of sentence. > > f. Page 3-27, section 3.8.5, third line of fifth paragraph. > Change > > "interfaces and abstract interface" to "interface and abstract > > interfaces". > > g. Page 3-27, table 3-10. Add new column for Abstract Interface > > following the column for Interface. Contents are the same as > > the existing column for Interface except that the entry for > > Stateful Value should be "supports". > > h. Page 3-27, table 3-10. Abstract Value inherits from Interface > > should be "supports single". Also add new row for Abstract > > Interface, > > with contents > > (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) > > no multiple no no no > > i. Page 6-2, add new numbered point 6 before existing point 6 > (which > > becomes point 7): Value types may support any number of > abstract > > interfaces, but no more than one regular interface. > > j. Page 10-16: Change the supported_interface parameter of the > > create_value method of Container to a parameter named > > supported_interfaces with a data type of InterfaceDefSeq. > > Also make this change on page 10-58. > > k. Page 10-19: Change supported_interface to supported_interfaces. > > l. Page 10-34: Change the supported_interface attribute of > ValueDef > > to a parameter named supported_interfaces with a data type of > > InterfaceDefSeq. Also make this change on page 10-64. > > m. Page 10-35: Change the supported_interface member of > ValueDescription > > to a member named supported_interfaces with a data type of > > RepositoryIdSeq. Also make this change on page 10-66. > > n. Page 10-36: Change the first paragraph of section 10.5.24.1 to > > "The supported_interfaces attribute lists the interfaces that > this > > value type supports." > > o. Page 10-36: In section 10.5.24.2, change supported_interface to > > supported_interfaces. > > > > Actions taken: > > January 20, 1999: received issue > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Date: Mon, 15 Feb 1999 23:12:04 +0000 From: Simon Nash Organization: IBM To: Jeffrey Mischkinsky CC: jis@fpk.hp.com, orb_revision@omg.org Subject: Re: Issue 2314 - multiple abstract interfaces References: <199902130531.VAA00836@wheel.dcn.davis.ca.us> Jeff, I don't think there is a problem here. Let's take as an example a valuetype V which supports two non-abstract interfaces X and Y. The hidden interface "XY" was needed for two reasons: 1. On the server side, to ensure that narrowing from X to Y works correctly, there needs to be a unique most derived interface. 2. On the client side, it is useful to have a stub corresponding to the most derived interface. This allows narrowing from X to Y to take place without a round trip to the server, if the client can use a stub for XY rather than for just X or just Y. Now let's change the example so that A and B are abstract interfaces and C is a valuetype that supports these. Because A and B are both abstract, when instances of C are passed through method signatures of type A or B, the C objects will be passed by value instead of by reference. (This is the crucial difference from the above case.) So on the client side, narrowing from A to B becomes a simple attempted cast of the runtime value object C. No stub is involved, no "is_a" request flows to the server, and there is no need for a synthesized "AB" interface. It is true that A and B will have stubs. These are needed in case a non-abstract interface such as D inherits from both A and B. In this case, if a D object is passed through a method signature type of A or B, the object is sent as an IOR and it may be necessary for the client to demarshal it as an _AStub or _BStub. However, there is no need for a synthesized most derived interface type AB since there is a real most derived interface type D that can be used for both server side narrowing and client side stubs. Simon Jeffrey Mischkinsky wrote: > > 'Simon Nash' writes: > > > > Jishnu, > > I guess it's up to me as proposer of this motion to start the ball > > rolling. > > > > The current prohibition on valuetypes supporting multiple > interfaces > > was intended to prevent the OBV spec introducing multiple > interface > > support by the "back door." The argument went that there is not > > much if any difference between a valuetype supporting multiple IDL > > interfaces and any implementation supporting sulitple IDL > interfaces. > > Since we had no standard way to do the latter, we should not > invent > > a standard way to do the former but not the latter, and we should > > not invent a standard way to do the latter as part of adding OBV. > > All very logical and reasonable. > > Simon, > I thought the reason we disallowed it was because it was > essentially > impossible to generate legal code which combined the > implementations > of each interface into one implementation, because of the way the > class > hierarchies work. In that sense it was sort of introducing > multiple > interface support. But it was not the fact of the pseudo interface > support that caused us to disallow it. > > The net result was that we had to create a "hidden" interface > which > multiply inherited from all the supported interfaces > (i.e. combined them > all into one interface) so that we were back to the single > supports case. > Except we had to figure out a mangled name for the "combination > interface" > which didn't conflict, and it turns out that it's not so > hidden. Since > it is in fact the class that the programmer has to use in her > code. > Hence, we decided allowing it wouldn't save us anything and in > fact > would complicate (and confuse) the user's life. > > When we talked about this issue internally we couldn't see > why this logic also wouldn't apply to abstract interfaces? Since > they > could in fact be real interfaces. At some point the implementor > has to provide a concrete implementation which will either be a > valuetype or an interface. So stubs/skeletons have to be able to > be > generated. > > What do you think? > > jeff > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb