From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,29d8139471e3f53e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!news.glorb.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Tue, 14 Sep 2010 21:08:16 +0300 Organization: Tidorum Ltd Message-ID: <8f9s0hFvvuU1@mid.individual.net> References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <874odv9npv.fsf@ludovic-brenta.org> <87y6b7cedd.fsf@mid.deneb.enyo.de> <66a3704c-54f9-4f04-8860-aa12f516134b@t3g2000vbb.googlegroups.com> <87d3sib44t.fsf@mid.deneb.enyo.de> <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net> <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net> <8f6cceFrv2U1@mid.individual.net> <8f97d6FobnU1@mid.individual.net> <1xjdyd281an6m$.1gymnlu3wjdcs.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net zi4OudXc4x0IfxgQV2dPOAPG6jonQXARZrorzE7B3Q7CjiYmOP Cancel-Lock: sha1:qzwmrqVgUt6Op4wffe/jf8kORG8= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: <1xjdyd281an6m$.1gymnlu3wjdcs.dlg@40tude.net> Xref: g2news1.google.com comp.lang.ada:14079 Date: 2010-09-14T21:08:16+03:00 List-Id: Dmitry A. Kazakov wrote: > On Tue, 14 Sep 2010 15:16:37 +0300, Niklas Holsti wrote: > >> If an operation of a parent type calls several other operations >> with redispatching, and several derived types override these called >> operations in diverse ways, perhaps you need to test the calling >> operation separately for each derived class. But if I understand >> Dmitry's standpoint correctly, he would avoid the redispatching by >> overriding the calling operation for each derived class, giving the >> same total number of operations to be tested, right? > > No, I am trying not to override non-abstract or non-null operations. Aha! *Now* I understand your concept. In other words, you are trying to avoid all inheritance of behaviour and to allow only inheritance of interfaces and perhaps of structure (components). I guess I can agree with you that such limitations can result in simple designs. I also see the connection (that you mentioned) to multiple inheritance. Still, I would not like to limit my designs in that way. > I think you have a certain way of decomposition in mind. This > decomposition is driven by the idea of re-dispatch or OOTIA's "simple > dispatch" or, more generally, by object's identity (rather than > contract). Possibly so. I have not knowingly modelled my design style on those sources, but may have absorbed such ideas when I first learned about object-oriented programming (and I no longer remember when that was). > I don't like this sort of decomposition in first place. That is your right, and may you live long and prosper. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .