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: Thu, 17 Apr 2014 00:44:37 +0300 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> <1wjmcbk375lzk.6o7dpqcp3va3.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 7e1xat4QQhOEYblNDXy/zg0oNRpreB08T3f/Umlu7QM8oMPhkn Cancel-Lock: sha1:i9A0GHy3QX9SLvmgM0rMsfXz93Y= 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:19338 Date: 2014-04-17T00:44:37+03:00 List-Id: On 14-04-15 03:08 , Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:br07nkFnvrbU1@mid.individual.net... > ... >> (This is why I don't understand your and Randy's abhorrence of >> re-dispatching -- to me, there is no basic difference between >> dispatching calls in class-wide operations, and re-dispatching calls in >> primitive operations.) > > I don't think it is a good idea to assume that Dmitry and I have the same > opinion on anything, even if the result appears to be the same. :-) I think I knew that... apologies if I implied differently (I see the smiley, thanks for the forbearance). > I view dispatching operations as the low-level primitives of a type, while > class-wide operations (which actually involve dispatching) as higher-level > operations of the type. In this you and Dmitry agree, it seems. In an earlier reply to Dmitry, I also agreed that class-wide operations are higher-level than primitive ops, but having thought a bit more, I want to modify that statement. Some of my class-wide operations are, rather, so fundamental for the class that I make them class-wide because I see no need to ever override them in any derived type of the class. But I'm not sure if we can equate "fundamental" with "low-level", architectural analogues notwithstanding ;-) > As such, a re-dispatching call means that there is > some sort of abstraction inversion going on, and that's usually (but not > always) bad. As I replied to Dmitry, my primitive operations tend to be layered, and redispatching usually goes from a higher-level to a lower-level operation. So I don't see this as abstraction inversion. > Dispatching operations necessarily have weaker contracts than statically > bound calls, and that is especially important for "contracts" that can't be > described in Ada and thus can't be checked (either statically or > dynamically). Hm, I'm not convinced of that. To me, the informal contract for a dispatching operation Foo is "implements the Foo operation as specified for the class and as appropriate for the actual type". Of course these specifications are given in comments. I don't see the "necessarily ... weaker" for the more formal contracts either. Yes, for a dispatching call there are more possible callee operations (implementations) to check against the contract, but the general contract (as experienced by the caller) can be the same for all. > After all, most extensions are created by someone other than > the originator of the original class, Not (sadly) the case for my applications. But sometimes years go by between the definition of the class and the addition of a derived type, so memory can play tricks, and I have had a few hiccups in that area. But not many, perhaps thanks to my obsessive commenting. > so violations of those implicit > contracts are bound to happen. (Errors happen any time humans are involved!) > Thus, you have much more confidence in operations that don't involve > re-dispatching -- as a practical matter, it is a lot easier to debug > statically bound calls rather than dispatching ones. I try to make my contracts explicit in comments. All I can say is that my experience does not agree with what you say. But the volume of my programming is not so large as to make a good empirical study. > Finally (really a restating of the last point), I find that it's fairly easy > to ensure that all of the primitive operations of a particular type have the > same world-view. That's not as true when some of the operations are assuming > the object is of type T, and some are re-dispatching to some TT derived from > T -- I've found many instances where some predicate of TT gets a different > answer than the same predicate of the same object viewed as a T. That sort > of things leads to all kinds of bugs, because not all of those predicates > are explicit in the code (even as statically bound calls). I'm not disputing your experience, but I haven't experienced the same. Perhaps there is some difference in our application areas that modulates the risks and benefits of redispatching. > This last issue doesn't arise for a class-wide operation, where every call > is going to look at an object of TT as type TT. Except if TT inherits some operation from T, because then that operation looks at the object as type T. (I know that from the language-semantics point of view the inherited operation acts on TT, but the programmer wrote its code with T in mind.) If redispatching is suspect because it breaks the assocation of an operation with a unique type, then inheritance of operations must also be suspect, for the same reason. I suppose one could forbid both inheritance and redispatching. That would be a major departure from traditional object/class-oriented programming. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .