Issue 3192: PSS FTF: Read-only operations on storage objects (pss-ftf) Source: ZeroC (Mr. Bernard Normier, bernard@zeroc.com) Nature: Uncategorized Issue Severity: Summary: With some object oriented programming languages (C++, Ada95), it is possible to specify a method as read-only or read-write. For example in C++, a 'const' member function has read-only access to the data members of the target object. So far in IDL and PSDL, there is no way to mark an operation as read-only -- this makes sense for interfaces, since a CORBA object exposes only operations, not state. For stateful objects, such as PSDL storage objects and IDL values, being able to specify an operation as read-only would be very useful. For example in C++ a 'in storage object' parameter could be mapped to a pointer to a const C++ object, which is exactly the semantics of 'in'. More generally, writing const-correct program in C++ (Ada etc.) with PSS would become possible. Resolution: accepted Revised Text: - Add an optional modifier to PSDL operations on abstract storage types: const. For example: abstract storagetype Account { readonly state long accno; void withdraw(in float amount); boolean overdraft_allowed() const; }; - The C++ mapping for a const operation is a const member function; the C++ mapping for a non read-only operation is a non-const member function. The C++ mapping for an 'in storage object' is a pointer to a const object, e.g. void foo(const SObj* in_sobj); The C++ mapping also provides var classes for const storage objects, (and assuming issue 3162 is resolved as proposed) ref classes that hold const storage objects plus var classes for such ref classes. For example: ConstAccountRef_var accref = acchome->find_ref_by_accno(1000); if (accref->overdraft_allowed()) { // ... } Since a pointer to a non-const can be implicitly converted into a pointer to const, a ref to non-const can be implicitly converted into a ref to const. As always, there is no implicit conversion between var classes. - Nothing changes for the Java mapping since Java has no read-only methods. See http://cgi.omg.org/pub/pss_ftf/proposals.pdf (color CYAN) Actions taken: January 7, 2000: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== Date: Fri, 07 Jan 2000 16:12:22 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: PSS FTF: Read-only operations on storage objects Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: R):!!=>dd985B!!S%c!! With some object oriented programming languages (C++, Ada95), it is possible to specify a method as read-only or read-write. For example in C++, a 'const' member function has read-only access to the data members of the target object. So far in IDL and PSDL, there is no way to mark an operation as read-only -- this makes sense for interfaces, since a CORBA object exposes only operations, not state. For stateful objects, such as PSDL storage objects and IDL values, being able to specify an operation as read-only would be very useful. For example in C++ a 'in storage object' parameter could be mapped to a pointer to a const C++ object, which is exactly the semantics of 'in'. More generally, writing const-correct program in C++ (Ada etc.) with PSS would become possible. Proposal: -------- - Add an optional modifier to PSDL operations on abstract storage types: readonly. For example: abstract storagetype Account { readonly state long accno; void withdraw(in float amount); readonly boolean overdraft_allowed(); }; - The C++ mapping for a readonly operation is a const member function; the C++ mapping for a non read-only operation is a non-const member function. The C++ mapping for an 'in storage object' is a pointer to a const object, e.g. void foo(const SObj* in_sobj); The C++ mapping also provides var classes for const storage objects, (and assuming issue 3162 is resolved as proposed) ref classes that hold const storage objects plus var classes for such ref classes. For example: ConstAccountRef_var accref = acchome->find_ref_by_accno(1000); if (accref->overdraft_allowed()) { // ... } Since a pointer to a non-const can be implicitly converted into a pointer to const, a ref to non-const can be implicitly converted into a ref to const. As always, there is no implicit conversion between var classes. - Nothing changes for the Java mapping since Java has no read-only methods. Regards, Bernard Date: Sat, 8 Jan 2000 08:29:46 +1000 (EST) From: Michi Henning To: Bernard Normier cc: issues@omg.org Subject: Re: PSS FTF: Read-only operations on storage objects In-Reply-To: <387656B6.545A9B84@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: +WXd9SIld9k0jd9'O`d9 On Fri, 7 Jan 2000, Bernard Normier wrote: > For example: > abstract storagetype Account > { > readonly state long accno; > void withdraw(in float amount); > readonly boolean overdraft_allowed(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }; I'm not sure that I like this syntax because it implies that the boolean is readonly, rather than the operation being const. > - The C++ mapping for a readonly operation is a const member function; > the C++ mapping for a non read-only operation is a non-const member > function. > The C++ mapping for an 'in storage object' is a pointer to a > const object, e.g. > void foo(const SObj* in_sobj); That would probably be better expressed as a const reference. > The C++ mapping also provides var classes for const storage objects, > (and assuming issue 3162 is resolved as proposed) ref classes that > hold const storage objects plus var classes for such ref classes. > For example: > > ConstAccountRef_var accref = acchome->find_ref_by_accno(1000); > if (accref->overdraft_allowed()) > { > // ... > } > > Since a pointer to a non-const can be implicitly converted into > a pointer to const, a ref to non-const can be implicitly converted > into a ref to const. As always, there is no implicit conversion > between var classes. I assume the idea is that you couldn't invoke a non-readonly operation via a ConstAccountRef_var? I'm a concerned about this suggestion. It isn't clear to me what this would for _ptr reference, which are currently always passed as non-const. Also, I'm not sure that we should go and add even more code to the already large mapping... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 07 Jan 2000 17:43:50 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: issues@omg.org Subject: Re: PSS FTF: Read-only operations on storage objects References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F=Wd9nVa!!i7:e95!Ke9 Hi Michi, Michi Henning wrote: > > On Fri, 7 Jan 2000, Bernard Normier wrote: > > > For example: > > abstract storagetype Account > > { > > readonly state long accno; > > void withdraw(in float amount); > > readonly boolean overdraft_allowed(); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > }; > > I'm not sure that I like this syntax because it implies that the > boolean > is readonly, rather than the operation being const. I have no problem with a C++-like syntax, e.g.: abstract storagetype Account { readonly state long accno; void withdraw(in float amount); boolean overdraft_allowed() const; }; ('readonly' instead of const is also fine with me). > > > - The C++ mapping for a readonly operation is a const member > function; > > the C++ mapping for a non read-only operation is a non-const > member > > function. > > The C++ mapping for an 'in storage object' is a pointer to a > > const object, e.g. > > void foo(const SObj* in_sobj); > > That would probably be better expressed as a const reference. Except that storage objects (like valuetypes) are generally handled through pointers or _vars. > > > The C++ mapping also provides var classes for const storage > objects, > > (and assuming issue 3162 is resolved as proposed) ref classes > that > > hold const storage objects plus var classes for such ref > classes. > > For example: > > > > ConstAccountRef_var accref = acchome->find_ref_by_accno(1000); > > if (accref->overdraft_allowed()) > > { > > // ... > > } > > > > Since a pointer to a non-const can be implicitly converted into > > a pointer to const, a ref to non-const can be implicitly > converted > > into a ref to const. As always, there is no implicit conversion > > between var classes. > > I assume the idea is that you couldn't invoke a non-readonly > operation > via a ConstAccountRef_var? Correct; a ConstAccountRef_var holds a ConstAccountRef, which behaves as a smart 'const Account*'. > > I'm a concerned about this suggestion. It isn't clear to me what > this would > for _ptr reference, which are currently always passed as non-const. As mentioned in my e-mail, this suggestion _does not_ apply to interfaces: a CORBA object does not expose any state, hence there is no point to have const CORBA objects, or references (_ptr) to const CORBA objects. On the other hand, since storage objects (like values and structs) expose state, const storage objects and references to a const storage objects make sense. Cheers, Bernard