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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Sat, 12 Apr 2014 00:04:48 +0200 Organization: Tidorum Ltd Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> <1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net> <17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 3V8aOkOkT+LjURUj11rWcwkBS/F5Yn08Mt4lY1vvNq98z1l275 Cancel-Lock: sha1:vtRZbnaf5ITCDQqXhy9iqElbt9E= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:19252 Date: 2014-04-12T00:04:48+02:00 List-Id: On 14-04-11 22:43 , Dmitry A. Kazakov wrote: > On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote: > >> On 14-04-10 17:31 , Dmitry A. Kazakov wrote: >>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: >> >> [snip] >> >>>> We don't want "type-specific" implementations of most things -- that's just >>>> adding a maintenance headache where one isn't needed. >>> >>> It is need for >>> >>> 1. safety (because you statically know that certain specific operation may >>> not fail, while class-wide operations can) >>> >>> 2. efficiency >>> >>> There is no maintenance overhead whatsoever. Here is the proof. Let you can >>> provide a generic implementation (as you suggested), then this >>> implementation can be safely inherited. >> >> If you change a class-wide operation to an inherited (i.e. primitive) >> operation, you have to change its dispatching calls to redispatching >> calls, if you want the same behaviour as for the class-wide operation. > > No. I meant that the behavior of class-wide operation was defined = there > were no re-dispatch to operations that could be overridden to some > unanticipated behavior. You mean that a class-wide operation should not call any primitive operations of its parameters? Your programming style / Ada subset is becoming "curiouser and curiouser". When _do_ you use dispatching? > Regarding use cases where re-dispatch comes in question, which certainly > exist, Ah, that is comforting. I thought you were totally against redispatch. > I think that from the safety and maintenance point of view, the type > system should provide means of body composition beyond simple inherit vs. > override. That is certainly an interesting issue. You are thinking of something of the same kind as the "inner" of Simula? In my own code, the primitive operations of a type are typically layered into levels: higher-level operations and lower-level ones. An overriding higher-level primitive operation is typically implemented by calling (with redispatch) lower-level primitive operations of the parameter object. The *same* (i.e. overridden) operation of the parent type is usually not called, nor does a primitive operation of a parent type call the same primitive operation from the actual derived type; only operations from lower layers are called. > We know, for example, that constructors (initialize) and > destructors (finalize) require other means of composition. More elaborated > composition tools should eliminate re-dispatch (and most class-wide > operations) => give safety and maintainability. Maybe... suggest something and we'll see. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .