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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Sat, 12 Apr 2014 10:20:04 +0200 Organization: cbb software GmbH Message-ID: <1wjmcbk375lzk.6o7dpqcp3va3.dlg@40tude.net> 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:19256 Date: 2014-04-12T10:20:04+02:00 List-Id: On Sat, 12 Apr 2014 00:04:48 +0200, Niklas Holsti wrote: > 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? They should, that was not the point. Which was maintainability. A class-wide operation cannot be more maintainable than a primitive operation. At least, it would require the level of contract thoroughness Ada presently does not possess, not even close. >> Regarding use cases where re-dispatch comes in question, which certainly >> exist, > > Ah, that is comforting. I thought you were totally against redispatch. Yes I am. Re-dispatch is a flawed solution to a real problem. I don't deny existence of the problem. I am against the solution, which is inherently unsafe and constraining (precludes by-copy semantics). >> 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? Yes, but it looks too low-level and hackish to me. The concept should somehow play together with the notion of polymorphic operation defined on the class (set of types). Between these two ends: independent bodies of a primitive operation and single body of a class-wide operation, there lies a whole spectrum of unexplored possibilities. > 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. Yes, this is the way I implement it too. The difference is that I try to keep "higher-level" operations class-wide. Then I try to maintain the "no abstraction inversion" rule, i.e. never call a "higher-level" operation from a "lower-level" one. Note that when "higher-level" operations are made class-wide, there is also a formalized separation of two, as they act on different types. >> 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. It is useless to suggest anything, as you know. And, I am not a language designer anyway. I am a programmer. As a programmer, from my experience with Ada, I tell the language designers that they got it all wrong since Ada 2005. I don't want yet another dynamically typed or functional language. I need a language for software engineering. More static checks, more means to make static checks possible. The whole language should revolute around helping restructuring my programs in order to support static checks. No Constraint_Error to me, please! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de