Issue 546: Trader Type repository breaks polymorphism (zz-trader) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The semantics of mandatory and read-only modifiers in the service type repository for trading are broken in the fact of inheritance. Resolution: Revised Text: Actions taken: April 21, 1997: received issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Mon, 21 Apr 1997 13:27:16 +1000 (EST) From: Michi Henning cc: trader-tech@dstc.edu.au Subject: Trader type repository breaks polymorphism Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues Hi, The semantics of mandatory and read-only modifiers in the service type repository for trading are broken in the face of inheritance. The spec allows a derived type to "strengthen" the modifiers of inherited properties in a derived type. For example, if a property in a base type is optional, the derived type can redefine the property as mandatory. Similarly, modifyable properties can be redefined as read-only in the derived type, but not the other way around. The idea of these restrictions is to preserve the guarantees established by the base type. Unfortunately, this breaks polymorphism. Consider the following service type definitions. A base type has a single property that is redefined by the derived type: type base prop name = size prop type = _tc_ushort prop mode = PROP_NORMAL // modifyable and optional type derived: base prop name = size prop type = _tc_ushort prop mode = PROP_MANDATORY_READONLY // mandatory and read-only Now consider a helper function which expects to deal with service offers of type base. The helper function exists to add or modify the value of the size property. Everything works fine, until I call this helper function with an instance of the derived service offer. The helper function now gets unexpected failures if it tries to add or modify the size property. So, the rules we have do *not* maintain all the guarantees of the base type. In particular, operations that are permitted on instances of the base type now no longer work on an instance of the derived type. This breaks inheritance ("a derived type is guaranteed to support all the operations of its base types"). I believe the spec should be changed to completely prohibit the redefinition of properties in derived types, otherwise we get the above problem. 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 Return-Path: Cc: issues@omg.org, trader-tech@dstc.edu.au Subject: Re: Trader type repository breaks polymorphism Date: Tue, 29 Apr 1997 17:55:20 +1000 From: Kerry Raymond Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues > The semantics of mandatory and read-only modifiers in the service type > repository for trading are broken in the face of inheritance. > The spec allows a derived type to "strengthen" the modifiers of inherited > properties in a derived type. For example, if a property in a base type > is optional, the derived type can redefine the property as mandatory. > Similarly, modifyable properties can be redefined as read-only in the derived > type, but not the other way around. > The idea of these restrictions is to preserve the guarantees established > by the base type. > Unfortunately, this breaks polymorphism. It depends on your point of view. If you consider it from the importer's point of view, then it is just fine. If you consider it from the exporter's point of view, then it is broken. The matter was discussed at some length in the merger process and the consensus was that the trader serves the importers as the primary "client" and hence the rules you see in the spec. I *thought* the spec mentioned this "point of view" but I don't have a copy close to hand to confirm this. > Now consider a helper function which expects to deal with service offers > of type base. The helper function exists to add or modify the value > of the size property. Everything works fine, until I call this helper > function with an instance of the derived service offer. The helper function > now gets unexpected failures if it tries to add or modify the size property. Since adding and modifying values is an exporter issue, it was never intended to work in this manner. Kerry >>>> 1st International Enterprise Distributed Object Computing Workshop <<<< >>>>>> Oct 24-26 1997 http://www.dstc.edu.au/events/edoc97/edoc.html <<<<<< ============================================================================= Dr Kerry Raymond, Architecture Unit Leader E-mail: kerry@dstc.edu.au CRC for Distributed Systems Technology Phone: +61 7 3365 4310 University of Queensland 4072 Australia Fax: +61 7 3365 4311 =========================================== WWW: http://www.dstc.edu.au/kerry Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 29 Apr 1997 18:12:23 +1000 (EST) From: Michi Henning cc: issues@omg.org, trader-tech@dstc.edu.au, trader-wg@foxtail.dstc.edu.au Subject: Re: Trader type repository breaks polymorphism Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues On Tue, 29 Apr 1997, Kerry Raymond wrote: > It depends on your point of view. If you consider it from the importer's > point of view, then it is just fine. If you consider it from the > exporter's point of view, then it is broken. The matter was discussed > at some length in the merger process and the consensus was that the trader > serves the importers as the primary "client" and hence the rules you > see in the spec. I *thought* the spec mentioned this "point of view" but > I don't have a copy close to hand to confirm this. I can't find such words in the spec, off-hand. Can someone point out to me where that is said? Regardless, I see your point - if I'm an importer, then what I care about mostly is that certain properties are guaranteed to be there, so I can write a meaningful query. However, I still think there is a problem with the semantics as defined. If I am an importer and import service offers of type "base", I may also get service offers of type "derived" (in the spirt of OO).. In the case I quoted, I will be able to update base offers, but not derived offers (not in the spirit of OO). The helper function could be something quite legitimate, for example to raise the interest rate property on all accounts for a bank by one percent. My point is that for the helper to work, it has to explicitly disable polymorphism by requiring an exact type match for the query. This of course is totally against the OO "spirit". In short, I'll stick to my guns - we have a derived type which does not preserve the semantics of all operations supported by its base type. This strikes me as something that definitely isn't OO. By the principle of least surprise, I think redefining property modes in derived types should be banned. Consider: I may have the above helper function already in place, and it has worked fine for many years. Now all of a sudden, someone creates a derived type, and makes the base type abstract by masking it. My trusty helper function now sees nothing but failures on every service offer it ever pulls back. Not nice... 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 Date: Wed, 21 Mar 2001 10:57:02 +1000 (EST) From: Michi Henning To: Juergen Boldt cc: issues@emerald.omg.org Subject: Re: Lost issues In-Reply-To: <4.2.0.58.20010320104951.00a86ca0@emerald.omg.org> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :BJe9a1K!!,[8e9=SL!! On Tue, 20 Mar 2001, Juergen Boldt wrote: > Hello all, > > URL http://cgi.omg.org/issues/issues.html > contains links to issues which have not been assigned to R/FTFs > because of > a couple of reasons: > ..to name a few... > a) The RTF/FTF has expired and should be re-chartered > b) The RTF/FTF has expired and will never be re-chartered again > (several > reasons why are possible) > c) I just didn't know what RTF/FTF would be responsible for an issue > submitted.. > d) There appear to be no RTFs for most of the CORBAservices > e) Nobody knew about this issues archive > > With your help some of those issues could be resolved (by assigning > some of > those issues to active RTFs/FTFs or by rechartering some of the > expired > RTFs...) Here are some proposals: Issue 184: Close no change. I don't understand the question Issue 468: Close. The issue is empty. Issue 493: Close no change. It doesn't because the submitters decided that it wouldn't. Issue 498: From what I can recall, this refers to name equivalence in the Naming Service. INS has cleaned this, so close it. Issue 961: Move to http://cgi.omg.org/issues/event-rtf.html Issue 2347: Close. This was fixed by INS. Issue 2972: Move to http::/cgi.omg.org/issues/relationship-rtf.html Issue 3003: Close. Issue 3271: Close no change. Historically, iterators in the various specs are a total mess, and all of them, without exception, get it wrong :-( I'm afraid we have to live with the resulting inconsistencies. Issue 4216: Should probably be reassigned to Core RTF? Issues 284, 546, 547, 548, 549, 550, 558, 559, 560, 561, 562, 4225: We need a trader RTF for those. The remaining open issues also will require formation of RTFs. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi