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, 19 Apr 2014 12:05:09 +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> <129pvrzqrv83p$.orkstybnskgo.dlg@40tude.net> <9b0anu6u678j.kfliatroezt0$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net v//fHi5d7E3yBsYOKBJUMA9u7soUxgfNVq+Lvc+A/yDmrakACR Cancel-Lock: sha1:EF9DGGTqGj3+z4UAIrUy8iUzt5E= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <9b0anu6u678j.kfliatroezt0$.dlg@40tude.net> Xref: news.eternal-september.org comp.lang.ada:19405 Date: 2014-04-19T12:05:09+03:00 List-Id: On 14-04-19 11:19 , Dmitry A. Kazakov wrote: > On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote: > >> On 14-04-19 00:18 , Dmitry A. Kazakov wrote: >>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: >>> >>>> (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. I think I misunderstood you here. I now think you meant that only the type-specific value (the second component of the tuple) is passed copy-in/copy-out (but the tag is not passed). I misunderstood and thought that you meant passing the entire tuple value (tag, type-specific value) by copy-in/out. >>>> 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. If the tag is not passed (as I now understood you meant), then redispatch is not possible, I agree. >>> Re-dispatching presumes the same object. >> >> No it doesn't. Why should it? Redispatch merely selects an operation >> based on the actual type (tag) of the parameter value. > > This is called dispatch. Yes, redispatch is a form of dispatch. >> Whether the >> operation acts on the same object or on a copy is a separate question. > > "Re-" presumes that dispatch happens again. What is in common to these two > instances of dispatch what makes it re-dispatch? The fact that the calling operation has been reached by a dispatch on the parameter's tag, and now a new dispatching call is made (dynamically within the first dispatching call) based on this same tag. This feature -- a first choice based on the tag, with a nested second choice based on the same tag -- was a feature of redispatching that you criticized in earlier discussions. > It is 1) the same > polymorphic operation and 2) the same object. Take either away and it is > not re-dispatch anymore: > > 1. Different operations: > > X.Foo; > X.Bar; -- This is not re-dispatch! Agreed, because the call to X.Bar does not occur in the body of Foo, so it does not occur dynamically within the first dispatching call. > 2. Different objects: > > X.Foo; > Y.Foo; -- This is not re-dispatch! Of course not. > In particular, the case, which is especially interesting and important for > by-copy types, when the derived type has a representation completely > different from the base. For instance: > > type Wide_Wide_Character is ...; -- Full Unicode > function Is_Digit (X : Wide_Wide_Character) return Boolean; > function Is_Letter (X : Wide_Wide_Character) return Boolean; > function Is_Alphanumeric (X : Wide_Wide_Character) return Boolean; > > type Character is new Wide_Wide_Character without parent's mess ...; > overriding function Is_Digit (X : Character) return Boolean; > overriding function Is_Letter (X : Character) return Boolean; > > Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter. Could you complete your thought here? I don't see a claim or a question yet. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .