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 X-Google-Thread: 103376,342dcd67e9ca73ee X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: tagged record child: override constructor? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1126591134.797303.318920@z14g2000cwz.googlegroups.com> <1uri5gd2n7om0.1ujkzb26ayxdx.dlg@40tude.net> <1126625009.709876.226260@f14g2000cwb.googlegroups.com> <225337460.SlYKbeB8eD@linux1.krischik.com> <87vf14him5.fsf@ludovic-brenta.org> <1idpvzxcxfckw.mrs8nw3eu4ks$.dlg@40tude.net> <13wyu4lwsmzmz.ktc3t2av54yv$.dlg@40tude.net> <1126705974.984997.227590@z14g2000cwz.googlegroups.com> <1126718176.448703.193860@g44g2000cwa.googlegroups.com> <1aroipmwspnb8.zqxtxhb4t06u$.dlg@40tude.net> <1126731371.081850.90860@g44g2000cwa.googlegroups.com> <12v93t1k4i81i$.sm5jmg8q3lpk$.dlg@40tude.net> <1126790380.573573.78220@g44g2000cwa.googlegroups.com> <1w82ustqd4vak$.mv9c3tcxa6sx.dlg@40tude.net> <1126810455.448696.262570@g44g2000cwa.googlegroups.com> <1126882356.112798.288440@g14g2000cwa.googlegroups.com> Date: Fri, 16 Sep 2005 23:03:30 +0200 Message-ID: <93g4w5iedrdj.qjv8pbklcryx$.dlg@40tude.net> NNTP-Posting-Date: 16 Sep 2005 23:02:26 MEST NNTP-Posting-Host: 9d5ca7f7.newsread2.arcor-online.net X-Trace: DXC=jL\VNnl:XZRkVRFeeUa4iQQ5U85hF6f;TjW\KbG]kaMXQ>n?D9BSA]\F8R>5X@G[JRWRXZ37ga[7ZAWU[gWam9fSVB>jQKIm\_[ X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4811 Date: 2005-09-16T23:02:26+02:00 List-Id: On 16 Sep 2005 07:52:36 -0700, Hyman Rosen wrote: > I still think > that Ada's requirement that tagged types be passed by reference > shows that it was a mistake for the language to try to conceal > the parameter passing mode from the programmer. Why do you think so? The program semantics should be independent from the parameter passing mode. The type identity is another thing. Though IMO, it is always suspicious from the design point view to have objects with identity. Fortunately Ada does not re-dispatch by default. I say fortunately, because it was a number of times were the compiler gave me the message, that a class-wide was expected, but a specific type was found instead. I can remember none of them, where the program were right. In C++ these errors would slip through. >> But the actual parameter may have another type. It leaks! > > Irrelevant. When the paramater is of a specific class type > and you pass a derived type as an argument, the parameter > simply receives a copy of the base part of the argument. > It's referred to as "slicing". And just as you claim to prefer, > once that happens there is no going back to the derived type. > The parameter is well and truly only of its declared type. But it is not a copy of the actual object. It is a copy of its part! The point is that T and T& are no less different C++ than T and T'Class in Ada. But in C++ T& is overloaded with two different meanings: closure of types (class) vs. reference type. As a consequence T& is always a reference to class (except from con/destructors (:-)) You cannot have a reference to a specific type. Same with pointers. In Ada both renaming (a rough equivalent of reference) and access types can be either specific or class-wide. Wasn't Java's final types an unsuccessful attempt to mend this? Further, because T& is not an object, you cannot do such elementary thing as to copy a polymorphic object. >> "A type is characterized by a set of values..." > > But what is the set of values for a tagged type? > Doesn't it include the values of all possible derived types? No. It is the class rooted in the type which do. A T'Class serves as a closure of all types derived from T. > After all, reading 4.6, it certainly seems that I'm allowed > to do view conversions back and forth between base and derived > tagged types. A view conversion is still a conversion. If all types had classes, then for non-tagged types T<->T'Class were a full conversions constructing new objects. In Ada there are things much close to this pattern. Unconstrained array types are similar to classes, their constrained subtypes are similar to specific types. Here bounds play the same role as the tag does. Note that the language does not define how bounds are passed back and forth. It also allows to pass arrays by copy and throw known bounds away. >> There is a great difference between not yet implemented things and ones >> which cannot be under any circumstances. > > The requirements for view conversion and by-refernce passing > make it seem to me that no Ada compiler will ever implement > your version of things. This is required for tagged types only. Let's wait until people finally turn sick of templates! (:-)) >> The argument "this" is first converted from B* to A*, then this->A::g() is >> called, then it is converted back to B*. > > And when this->A::g() calls f(), it does so by dispatching, regardless > of whether the A::g() call originated in a constructor or not. Don't you see that the following two interpretations are equivalent: 1. It dispatches, but the tag changes 2. It does not dispatch, and the tag is constant. It is clear that you prefer (1) because your mental model is many types - one object. But I stick to (2) because I am convinced that the multiple types model will show itself infeasible, should somebody try to formalize it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de