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: Fri, 18 Apr 2014 22:10:50 +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> <1kwpgk4mrnzey.18388dob823vp$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net unvFtOuxa3ZwlrReQVDtcAQyQs53yZdH1W20TA09Pb2MOlBNEq Cancel-Lock: sha1:qHwWgYdw0uscMlgtEHDf2p3PayQ= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <1kwpgk4mrnzey.18388dob823vp$.dlg@40tude.net> Xref: news.eternal-september.org comp.lang.ada:19380 Date: 2014-04-18T22:10:50+03:00 List-Id: (Apologies for a delayed reply.) On 14-04-14 00:07 , Dmitry A. Kazakov wrote: > On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: > >> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: > >>> I don't deny >>> existence of the problem. I am against the solution, which is inherently >>> unsafe and constraining (precludes by-copy semantics). >> >> But class-wide operations which contain dispatching calls also preclude >> by-copy semantics, don't they? > > Not at all. There is no problem for a class-wide operation to act on > by-copy types. > > A by-copy class-wide object is a tuple (tag, type-specific value). Upon > dispatch the value is passed copy-in/copy-out to the type specific > operation. OK, but from the implementation point of view, that form of by-copy passing could be used for all operations of a tagged class, whether class-wide or primitive, with or without redispatching. So it is not evident why you said earlier that redispatching prevents by-copy semantics. If I may guess, your reasoning is perhaps that if we have a tagged type T, and a derived type TT with added components, and a primitive operation Foo on T which is inherited by TT and uses by-copy semantics, then calling Foo on a TT object X should really copy only the T part of X, and therefore Foo could not execute a redispatching call to some operation Bar on T which is overridden for TT, because the conversion T'Class(X) in the redispatching call would have no way to (re)generate the TT components of X, because they were not copied. I think that argument is wrong from the formal point of view, because when Foo is inherited from T to TT, the inherited operation formally acts on TT, therefore the by-copy passing would copy all of X, including the TT components. Another case that comes to mind is an explicit call to the original (not inherited) form of Foo, using a call with a conversion of the form Foo(T(X)) where X is of type TT. Here, there is more reason to feel that by-copy passing should copy only the T part of X (or, rather, the conversion should return only the T part of X), and then redispatching from Foo would indeed be impossible. But if T(X) is seen simply as a view conversion, not a value conversion, then X could still be passed by-copy using your (tag, type-specific value) form. (Of course this is all irrelevant to current Ada, where tagged types are by-reference and T(X) in the call is a view conversion.) >> A class-wide operation, in my view, is just like a primitive operation >> except that (1) (re-)dispatching is implicit and automatic for all calls >> to primitive operations of the parameter object (because the parameter >> is a class-wide type) and (2) the operation cannot be overridden. > > There is no re-dispatching in a class-wide operation. It is defined on > class-wide objects, so it simply neither dispatch nor re-dispatch. Huh? If a class-wide operation calls a primitive operation, using a controlling parameter of the class-wide type, that is certainly a dispatching call. >> (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.) > > The difference is in types involved. A body of a primitive operation is > defined on a particular specific type. A re-dispatch within the body > breaks this type contract by calling an operation defined on *another* > type. This is an untyped behavior. Not in my opinion, of course. In any primitive operation, I consider a parameter of type T to be just a T-view of an object which may be of type T or of a derived type. This matches how Ada is now defined and implemented; your statement reflects another language, or an Ada subset. I'll stop arguing about redispatching for now. Our views are different. The only reason I entered this discussion about redispatching is that I am upset when someone (often you, Dmitry) makes the blank statement that one should "never redispatch", as if redispatching would lead to erroneous execution and program crashes as surely as reading an uninitialized variable might. Redispatching is well defined in Ada and does not cause erroneous execution or bounded errors. The only arguments against redispatching either come from a more constrained idea of types (effectively an Ada subset) or from a fear of increased dynamic choice of callees, in particular fear of choosing an inappropriate operation of a different type. Both arguments concern design and coding styles and their impact on the likelihood of design or coding errors, not of correct or erroneous execution. My objective has only been to make this clear to people who might be misled by the blanket condemnations of redispatching. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .