Issue 601: Section 17..13.1 release()method should be added to mappping (cxx_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The Object IDL contains a release() mmethod that is not mapped in the C++ mapping. This method should be added in the mapping Resolution: clarified Revised Text: Actions taken: July 9, 1997: received issue February 19, 1999: closed issue Discussion: End of Annotations:===== Return-Path: To: cxx_revision@omg.org cc: orb_revision@omg.org Subject: testsuite issue Date: Wed, 09 Jul 1997 16:05:32 +0100 From: Stephen McNamara Section 17.13.1 The Object IDL contains a release() method that is not mapped in the C++ mapping. This method should be added in the mapping. stephen Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Wed, 09 Jul 1997 15:25:46 -0400 To: Stephen McNamara From: Steve Vinoski Subject: Re: testsuite issue Cc: cxx_revision@omg.org, orb_revision@omg.org At 04:05 PM 7/9/97 +0100, Stephen McNamara wrote: > >Section 17.13.1 > >The Object IDL contains a release() method that is not mapped in the >C++ mapping. This method should be added in the mapping. Hi Stephen, It is in the mapping, but it's called CORBA::release() so that it can safely be invoked on nil object references (object->release() is not allowed in C++ if "object" is a null pointer). Many of the C++ issues you've raised are centered around whether language mappings are allowed to move operations (such as moving Object::release to CORBA::release) and add other operations (such as CORBA::string_alloc) for the sake of making CORBA more natural for programmers who use that language. I would argue strongly that this must be the case, otherwise the strengths of different programming languages get lost and implementors get stuck with only the features available in the lowest common denominator programming language subset. Moving, renaming, and adding things to make the mapping more natural for C++ developers is certainly the approach we took for the C++ mapping. Developers expecting to only be able to look at some IDL and automatically know how to use it in any language are fooling themselves -- they *must* know the language mappings for the languages they want to use. --steve Return-Path: To: Steve Vinoski Cc: cxx_revision@omg.org, orb_revision@omg.org Subject: Re: testsuite issue Date: Thu, 10 Jul 1997 12:56:19 +0100 From: Stephen McNamara >At 04:05 PM 7/9/97 +0100, Stephen McNamara wrote: >> >>Section 17.13.1 >> >>The Object IDL contains a release() method that is not mapped in the >>C++ mapping. This method should be added in the mapping. > >Hi Stephen, > >It is in the mapping, but it's called CORBA::release() so that it can >safely be invoked on nil object references (object->release() is not >allowed in C++ if "object" is a null pointer). > >Many of the C++ issues you've raised are centered around whether >language mappings are allowed to move operations (such as moving >Object::release to CORBA::release) and add other operations (such as >CORBA::string_alloc) for the sake of making CORBA more natural for >programmers who use that language. I would argue strongly that this >must be the case, otherwise the strengths of different programming >languages get lost and implementors get stuck with only the features >available in the lowest common denominator programming language >subset. Moving, renaming, and adding things to make the mapping more >natural for C++ developers is certainly the approach we took for the >C++ mapping. Developers expecting to only be able to look at some >IDL and automatically know how to use it in any language are fooling >themselves -- they *must* know the language mappings for the >languages they want to use. > >--steve Its a good point, programming to the lowest common level of interoperability means you get the worst of all worlds. However we really need a definitive statement of whats what in CORBA. IDL methods that are not mapped need to be justified - even if its just what you said above. I dont think it harms, in fact I strongly believe it improves the specification to include some of the justifications for divergence from the normative mappings instead of statements that appear to contradict other portions of the document. Indivduals know this information but its been lost (intentionally or otherwise) from the final documents which, I believe, makes the specification poorer. stephen Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Fri, 11 Jul 1997 09:27:44 +1000 (EST) From: Michi Henning To: Stephen McNamara cc: Steve Vinoski , cxx_revision@omg.org, orb_revision@omg.org Subject: Re: testsuite issue On Thu, 10 Jul 1997, Stephen McNamara wrote: > Indivduals know this information but its been lost (intentionally or > otherwise) from the final documents which, I believe, makes the > specification poorer. I agree. There are quite a few places in the core and services specs where something on the surface looks a bit strange, but a good reason exists for why things are that way. What is missing in many places is a rationale. Quite often, a sentence or two would make things a lot clearer. It would also stop people from wondering "Now why didn't they do it like so...?" I'm all in favour of supplementing specifications with rationale. We could have a special font or paragraph format for these to indicate that they are non-normative comments. I believe adding rationale to the specs would improve them substantially. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html