Issue 2256: PSS requiremnets for the ObV/Java mapping (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The latest ObV/Java mapping, including George"s latest proposal, is not usable for values with a persistent implementation. I"d really like to solve this issue with the Java & ObV RTF, rather than solve it through the adoption of a new spec that updates the Java mapping. ==== Issue - ObV/Java maps value types"s data members to Java data members - providing a persistent implementation for such data members would require byte-code post-processing or pre-processing, or yet-to-be-specd-and-agreed JVM hooks; we do not see this as viable/ realistic options. Resolution: closed, no action Revised Text: Actions taken: December 15, 1998: received issue June 4, 1999: closed issue Discussion: Persistent valuetypes are part of a proposed submission to the PSS RFP which has not yet been adopted. If and when such a submission is adopted as an OMG specification, it MAY be appropriate to resubmit this, or a similar issue. Until then, even the filing of this issue is premature at best. End of Annotations:===== Return-Path: Date: Mon, 23 Nov 1998 11:26:40 -0500 From: Bernard Normier Organization: IONA Technologies To: java-rtf@omg.org CC: obv-rtf@omg.org Subject: PSS requirements for the ObV/Java mapping The latest ObV/Java mapping, including George's latest proposal, is not usable for values with a persistent implementation. I'd really like to solve this issue with the Java & ObV RTF, rather than solve it through the adoption of a new spec that updates the Java mapping. ==== Issue - ObV/Java maps value types's data members to Java data members - providing a persistent implementation for such data members would require byte-code post-processing or pre-processing, or yet-to-be-specd-and-agreed JVM hooks; we do not see this as viable/ realistic options. ==== Requirements There are various ways to address this issue, and I am not a priori against any solution. However, an acceptable solution would need to be (1) simple to use and (2) allow the same abstract base class to be used as a value with a transient implementation or with a persistent implementation. ==== Possible solutions Any solution that augments the IDL valuetype notation (e.g. add a persistent keyword, use an optional 'abstract' qualifier to valuetype data members) is somewhat flawed since the current IDL notation is perfectly suitable for C++; it's really a Java mapping issue, not an issue with the valuetype notation. The simplest solution would certainly be to map IDL data members to abstract accessors and modifiers, like in C++, but I understand that a number of people here are strongly opposed to this "hard-to-use" mapping. So we could have two mandatory mappings -- one with data members and one with methods -- and let the user make the trade-off between ease-of-use (direct data access) and flexibility (various state implementation thanks to methods) through some unspecified IDL compiler switch, pragma ... "a tool issue". Defining value classes with different names of each of these mapping seems difficult -- who would get the IDL name ? It would also be very complex to implement, e.g. when the IDL compiler sees an operation like void op(in AValueType a); it would have to know the mapping selected for AValueType, rather than simply generate void op(AValueType a); // don't care how AValueType looks like -- it could even be a forward declaration. Since the new revised deadline for PSS submissions is in less than a month (12/21), it would be nice to reach an agreement soon... Thanks, Bernard Return-Path: Date: Mon, 14 Dec 1998 15:10:01 -0500 From: Bernard Normier Organization: IONA Technologies To: java-rtf@omg.org CC: obv-rtf@omg.org, "omg-integration@poet.com" Subject: ObV/Java mapping proposal (was PSS requirements for the ObV/Java mapping) References: <36598CC0.9AF16711@iona.com> The best solution seems to let the user make the trade-off between implementation flexibility (i.e. methods to access state) and ease of use (i.e. data fields represent state). I propose to define a pragma to ensure that the mapping choice is consistent -- consistency is necessary to execute in the same JVM several Java programs using the same valuetypes. The proposed pragma is a concrete-valuetype body pragma [comparable to interface body pragmas, described in 3.7.3 of the CORBA spec]. It's defined as follows: #pragma Java {generate_fields | generate_methods | from_reverse_mapping} o generate_fields means to map the data members of this concrete valuetype to Java data fields (as in the latest Java mapping). o generate_methods means to map each data member of this concrete valuetype to a pair of abstract Java accessor and modifier methods (as in the current C++ mapping). o from_reverse_mapping tells the IDL compiler that this valuetype comes from an existing Java class -- the IDL compiler should not generate a new abstract Java class for this valuetype. For example: abstract valuetype A { // abstract value -- doesn't need any pragma void op(); }; // forward declaration -- doesn't need any pragma valuetype B; // concrete valuetype with its body valuetype B { #pragma Java generate_fields // the IDL compiler will generate a public field for this data member // (like today) public string name; }; This would not be the only pragma with a real effect on the Java mapping: #pragma ID already specifies the package in which the generated Java code goes. Best regards, Bernard Bernard Normier wrote: > > The latest ObV/Java mapping, including George's latest proposal, is > not > usable for values with a persistent implementation. > I'd really like to solve this issue with the Java & ObV RTF, rather > than > solve it through the adoption of a new spec that updates the Java > mapping. > > ==== Issue > - ObV/Java maps value types's data members to Java data members > - providing a persistent implementation for such data members would > require byte-code post-processing or pre-processing, or > yet-to-be-specd-and-agreed JVM hooks; we do not see this as > viable/ > realistic options. > > ==== Requirements > There are various ways to address this issue, and I am not a priori > against any solution. However, an acceptable solution would need to > be (1) simple to use and (2) allow the same abstract base class to > be > used as a value with a transient implementation or with a persistent > implementation. > > ==== Possible solutions > Any solution that augments the IDL valuetype notation (e.g. add a > persistent keyword, use an optional 'abstract' qualifier to > valuetype > data members) is somewhat flawed since the current IDL notation is > perfectly suitable for C++; it's really a Java mapping issue, not an > issue with the valuetype notation. > > The simplest solution would certainly be to map IDL data members to > abstract accessors and modifiers, like in C++, but I understand that > a number of people here are strongly opposed to this "hard-to-use" > mapping. So we could have two mandatory mappings -- one with data > members and one with methods -- and let the user make the trade-off > between ease-of-use (direct data access) and flexibility (various > state implementation thanks to methods) through some unspecified > IDL compiler switch, pragma ... "a tool issue". > Defining value classes with different names of each of these mapping > seems difficult -- who would get the IDL name ? It would also be > very > complex to implement, e.g. when the IDL compiler sees an operation > like > void op(in AValueType a); > it would have to know the mapping selected for AValueType, rather > than simply generate > void op(AValueType a); // don't care how AValueType looks like -- it > could even be a forward declaration. > > Since the new revised deadline for PSS submissions is in less than a > month (12/21), it would be nice to reach an agreement soon... > > Thanks, > > Bernard Return-Path: Sender: jis@fpk.hp.com Date: Mon, 14 Dec 1998 19:23:08 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Simon Nash CC: Bernard Normier , java-rtf@omg.org, obv-rtf@omg.org, "omg-integration@poet.com" Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV/Java mapping) References: <36598CC0.9AF16711@iona.com> <36757099.E971EF72@iona.com> <36759DD3.3C4F8B37@hursley.ibm.com> Simon Nash wrote: > Bernard Normier wrote: > > > > The best solution seems to let the user make the trade-off > > between implementation flexibility (i.e. methods to access state) > and > > ease of use (i.e. data fields represent state). > > > > I propose to define a pragma to ensure that the mapping choice is > > consistent -- consistency is necessary to execute in the same JVM > > several Java programs using the same valuetypes. > > > I dislike this approach. Adding language-specific pragmas to IDL > would > be a large step in the wrong direction. I agree with Simon. I think it was a mistake to use prgmas for Version, ID etc. in the first place. If those concepts are important for specification new language constructs should have been added to express them. I think that mistake would be further compunded by adding mroe pragmas, and language binding specific ones at that. 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. Return-Path: Date: Mon, 14 Dec 1998 20:33:52 -0500 From: Bernard Normier Organization: IONA Technologies To: Jishnu Mukerji CC: Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) References: <882566DB.0001EDF1.00@mail.poet.com> Jishnu Mukerji wrote: > > Simon Nash wrote: > > Bernard Normier wrote: > > > > > > The best solution seems to let the user make the trade-off > > > between implementation flexibility (i.e. methods to access > state) and > > > ease of use (i.e. data fields represent state). > > > > > > I propose to define a pragma to ensure that the mapping choice > is > > > consistent -- consistency is necessary to execute in the same > JVM > > > several Java programs using the same valuetypes. > > > > > I dislike this approach. Adding language-specific pragmas to IDL > would > > be a large step in the wrong direction. > > I agree with Simon. I think it was a mistake to use prgmas for > Version, > ID etc. in the first place. If those concepts are important for > specification new language constructs should have been added to > express > them. I think that mistake would be further compunded by adding mroe > pragmas, and language binding specific ones at that. > I hope you do not mean "new IDL contructs". IDL constructs are used to express language-neutral concepts, not to provide language-mapping specific information, such as "in which package this generated Java class goes", or "in JAVA, which mapping to use for this valuetype's data members?". Besides pragmas, CORBA does not provide any mechanism to express such language-mapping specific stuff ... what are you proposing? Regards, Bernard Return-Path: Date: Mon, 14 Dec 1998 18:17:13 PST Sender: Bill Janssen From: Bill Janssen To: Bernard Normier , Simon Nash Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV/Java mapping) CC: java-rtf@omg.org, obv-rtf@omg.org, "omg-integration@poet.com" References: <36598CC0.9AF16711@iona.com> <36757099.E971EF72@iona.com> <36759DD3.3C4F8B37@hursley.ibm.com> Excerpts from local.omg: 14-Dec-98 Re: ObV/Java mapping propos.. Simon Nash@hursley.ibm.c (2317*) > I dislike this approach. Adding language-specific pragmas to IDL would > be a large step in the wrong direction. Pragmas in general are a bad idea. Language-specific directives may not be, however. They should be made part of IDL, though, instead of done via the #pragma mechanism. Bill Return-Path: Date: Mon, 14 Dec 1998 18:22:08 PST Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Bernard Normier Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) CC: Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration References: <882566DB.0001EDF1.00@mail.poet.com> <3675BC80.24767032@iona.com> Bernard, I see no reason why IDL constructs could not be used to provide direction to CORBA tools dealing with specific languages, operating systems, etc. For instance, imagine a "mapping" attribute on interfaces which would override the default mapping name of the interface type to a programming language type: interface Foo { mapping "C++" "specialFoo"; mapping "Java" "com.xerox.parc.ilu.niftyFoo"; ... }; I think there are some costs to using such constructs, such as increasing the conceptual complexity of the mapping of Foo. However, if there are benefits as well, the trade-offs should be considered before decideing whether or not to reject the concept. Bill Return-Path: Date: Tue, 15 Dec 1998 12:25:21 +1000 (EST) From: Michi Henning To: Bernard Normier cc: Jishnu Mukerji , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) Organization: Triodia Technologies On Mon, 14 Dec 1998, Bernard Normier wrote: > > I agree with Simon. I think it was a mistake to use prgmas for Version, > > ID etc. in the first place. If those concepts are important for > > specification new language constructs should have been added to express > > them. I think that mistake would be further compunded by adding mroe > > pragmas, and language binding specific ones at that. > > > > I hope you do not mean "new IDL contructs". IDL constructs are used to > express language-neutral concepts, not to provide language-mapping > specific information, such as "in which package this generated Java > class goes", or "in JAVA, which mapping to use for this valuetype's > data members?". Well, it's IDL, which is meant to be language independent. Adding language-specific things to IDL is most definitely a step in wrong direction. > Besides pragmas, CORBA does not provide any mechanism to express such > language-mapping specific stuff ... what are you proposing? It's not meant to be in IDL, that's why there is no mechanism. I would strongly argue for a solution that does not augment the IDL with mapping-specific information. After all, we've managed to add OBV and Messaging without doing this, so surely, there must be a way to achieve it for PSS as well? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Tue, 15 Dec 1998 12:57:29 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, "omg-integration@poet.com" Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV/Java mapping) Organization: Triodia Technologies On Mon, 14 Dec 1998, Bill Janssen wrote: > Pragmas in general are a bad idea. Language-specific directives may not > be, however. They should be made part of IDL, though, instead of done > via the #pragma mechanism. No, please -- next thing I know, I'll have IDL that's adorned with annotations for Java, C++, Python, COBOL, etc. just in case that someone wants to build a client or server in that language. That definitely strikes me as the wrong way to go. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Tue, 15 Dec 1998 13:00:30 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jishnu Mukerji , Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) Organization: Triodia Technologies On Mon, 14 Dec 1998, Bill Janssen wrote: > Bernard, > > I see no reason why IDL constructs could not be used to provide > direction to CORBA tools dealing with specific languages, operating > systems, etc. For instance, imagine a "mapping" attribute on > interfaces > which would override the default mapping name of the interface type > to a > programming language type: > > interface Foo { > > mapping "C++" "specialFoo"; > mapping "Java" "com.xerox.parc.ilu.niftyFoo"; > > ... > }; > > I think there are some costs to using such constructs, such as > increasing the conceptual complexity of the mapping of Foo. > However, if > there are benefits as well, the trade-offs should be considered > before > decideing whether or not to reject the concept. Again, I am not all at ease with that suggestion. Implementation is just that, implementation. It should most definitely stay out of the IDL. Why do we all of a sudden have this need to dilute the separation of interface and implementation? That is one of the strongest aspects of CORBA and fundamental to the object model. I would consider any move toward implementation-specific annotations in IDL as a severe deviation from the OMA. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Mon, 14 Dec 1998 19:10:26 PST Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Michi Henning Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV/Java mapping) CC: Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, "omg-integration@poet.com" References: Excerpts from direct: 14-Dec-98 Re: ObV/Java mapping propos.. Michi Henning@triodia.co (770*) > No, please -- next thing I know, I'll have IDL that's adorned with annotations > for Java, C++, Python, COBOL, etc. just in case that someone wants to > build a client or server in that language. That definitely strikes me as > the wrong way to go. I share your concern, of course. But perhaps we should depend on self-restraint to prevent this from occurring, rather than denying people the mechanism. Bill Return-Path: Date: Tue, 15 Dec 1998 13:14:00 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, "omg-integration@poet.com" Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV/Java mapping) Organization: Triodia Technologies On Mon, 14 Dec 1998, Bill Janssen wrote: > I share your concern, of course. But perhaps we should depend on > self-restraint to prevent this from occurring, rather than denying > people the mechanism. Emphatically no. Self-restraint does not work, I've learned that from bitter experience. Once a feature is available, developers will abuse it in every imaginable way, plus a number of unimaginable ones. Often, that happens out of ignorance rather than intent. Sometimes, it happens out of desperation ("We need to get this out the door, to hell with the consequences.") Cheers, Michi. Copyright 1998 Michi Henning. All rights reserved. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: To: Michi Henning cc: Bill Janssen , Jishnu Mukerji , Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) Date: Tue, 15 Dec 1998 14:48:55 +1000 From: Keith Duddy >> I see no reason why IDL constructs could not be used to provide >> direction to CORBA tools dealing with specific languages, operating >> systems, etc. For instance, imagine a "mapping" attribute on >> interfaces >> which would override the default mapping name of the interface type >> to a >> programming language type: >> >> interface Foo { >> >> mapping "C++" "specialFoo"; >> mapping "Java" "com.xerox.parc.ilu.niftyFoo"; >> >> ... >> }; >> >> I think there are some costs to using such constructs, such as >> increasing the conceptual complexity of the mapping of Foo. >> However, if >> there are benefits as well, the trade-offs should be considered >> before >> decideing whether or not to reject the concept. > >Again, I am not all at ease with that suggestion. Implementation is >> just >that, implementation. It should most definitely stay out of the IDL. Surprise Surprise - I agree with Michi. If we look at what's happening with the CORBA Components specification (our first _real_ foray into specifying implementation packaging syntax) you'll see that we are defining other files that refer to their types by referencing IDL or the IR, but do not attempt to add any non-type information to IDL. Several ORB products in the past have had config files that associate implementations with IDL types (Object Broker & ORB plus spring to mind). Standardising these sort of mapping files is a better way to go IMO than augmenting IDL. K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: Sender: jis@fpk.hp.com Date: Tue, 15 Dec 1998 10:59:54 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Bernard Normier CC: Simon Nash , java-rtf@omg.org, obv-rtf@omg.org Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) References: <882566DB.0001EDF1.00@mail.poet.com> <3675BC80.24767032@iona.com> Bernard Normier wrote: > > Jishnu Mukerji wrote: > > > > Simon Nash wrote: > > > Bernard Normier wrote: > > > > > > > > The best solution seems to let the user make the trade-off > > > > between implementation flexibility (i.e. methods to access > state) and > > > > ease of use (i.e. data fields represent state). > > > > > > > > I propose to define a pragma to ensure that the mapping choice > is > > > > consistent -- consistency is necessary to execute in the same > JVM > > > > several Java programs using the same valuetypes. > > > > > > > I dislike this approach. Adding language-specific pragmas to > IDL would > > > be a large step in the wrong direction. > > > > I agree with Simon. I think it was a mistake to use prgmas for > Version, > > ID etc. in the first place. If those concepts are important for > > specification new language constructs should have been added to > express > > them. I think that mistake would be further compunded by adding > mroe > > pragmas, and language binding specific ones at that. > > > > I hope you do not mean "new IDL contructs". IDL constructs are used > to > express language-neutral concepts, not to provide language-mapping > specific information, such as "in which package this generated Java > class goes", or "in JAVA, which mapping to use for this valuetype's > data members?". > Besides pragmas, CORBA does not provide any mechanism to express > such > language-mapping specific stuff ... what are you proposing? What I am suggesting somewhat obliquely is the following: (1) IDL should contain only those pieces of information that are relevant to the abstract specification of the interface contract, and to express these there should be IDL language constructs and keywords. (2) Ideally anything else should not be in IDL. They should be found elsewhere, appropriately linked to IDL defined types etc. However, if it is felt that there is a need to "annotate" IDL with additional information, and said perceived need is adequately justified, then an IDL construct for expressing such annotations with precise specification of the semantics of said annotation should be provided and used. I believe that pragmas should not be used in specifying standards. If a concept rightfully belongs in interface specification like the interfaces version or its fully qualified name (stuff that goes in the interface repository in some sense) then an IDL construct should be added to IDL to express this information. Adding information to IDL to tweak language mapping details is somewhat questionable I think, not that it has not been done by others in different ways in different places. But if you can make a cogent case that it is part of the abstract contract then either (a) figure out a way of using currently available facilities in the IDL (not pragmas) to express it or (b) extend IDL to enable expression of said concept. So what I am proposing is - find a way other than using pragmas. Keith Duddy mentioned a possible approach for doing such things in his message excerpted below: > If we look at what's happening > with the CORBA Components specification (our first _real_ foray into > specifying implementation packaging syntax) you'll see that we are > defining other files that refer to their types by referencing IDL or > the IR, but do not attempt to add any non-type information to IDL. > Several ORB products in the past have had config files that > associate > implementations with IDL types (Object Broker & ORB plus spring to > mind). Standardising these sort of mapping files is a better way to > go > IMO than augmenting IDL. 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. Return-Path: From: jrhyne@us.ibm.com X-Lotus-FromDomain: IBMUS To: Michi Henning cc: Bill Janssen , Jishnu Mukerji , Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration Date: Tue, 15 Dec 1998 17:16:51 -0500 Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) Content-Disposition: inline At the risk of polluting the mailboxes further, I would observe that we are simply reusing IDL as a specification language rather than inventing a new language. I would also observe that, in the case of Simon's abstract valuetype proposal, we can reuse the language bindings too. Jim Jim Rhyne, STSM, Component Broker Tool Architect jrhyne@us.ibm.com, 416 448 4383 IBM Canada Ltd. 2G/846/1150/TOR 1150 Eglinton Ave. E., Toronto, Ont. M3C 1H7 CANADA Michi Henning on 12/14/98 10:00:30 PM To: Bill Janssen cc: Jishnu Mukerji , Bernard Normier , Simon Nash , java-rtf@omg.org, obv-rtf@omg.org, omg-integration (bcc: Jim Rhyne/Somers/IBM) Subject: Re: ObV/Java mapping proposal (was PSS requirements for the ObV /Java mapping) On Mon, 14 Dec 1998, Bill Janssen wrote: > Bernard, > > I see no reason why IDL constructs could not be used to provide > direction to CORBA tools dealing with specific languages, operating > systems, etc. For instance, imagine a "mapping" attribute on interfaces > which would override the default mapping name of the interface type to a > programming language type: > > interface Foo { > > mapping "C++" "specialFoo"; > mapping "Java" "com.xerox.parc.ilu.niftyFoo"; > > ... > }; > > I think there are some costs to using such constructs, such as > increasing the conceptual complexity of the mapping of Foo. However, if > there are benefits as well, the trade-offs should be considered before > decideing whether or not to reject the concept. Again, I am not all at ease with that suggestion. Implementation is just that, implementation. It should most definitely stay out of the IDL. Why do we all of a sudden have this need to dilute the separation of interface and implementation? That is one of the strongest aspects of CORBA and fundamental to the object model. I would consider any move toward implementation-specific annotations in IDL as a severe deviation from the OMA. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html