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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,dbcfe2b0a74da57e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!o80g2000hse.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Thu, 27 Sep 2007 14:23:58 -0700 Organization: http://groups.google.com Message-ID: <1190928238.269866.53270@o80g2000hse.googlegroups.com> References: <1190296353.624737.150940@y42g2000hsy.googlegroups.com> <11m13st1f92kf$.m8s6y8mc8ebk.dlg@40tude.net> <1190321119.206313.65290@57g2000hsv.googlegroups.com> <1190408526.100291.265040@50g2000hsm.googlegroups.com> <9ukf2wtqjs0q$.iuijmal4x56b$.dlg@40tude.net> <1190497995.498679.119190@19g2000hsx.googlegroups.com> <1mw3qju08q8uj.sgzht7ld9ydc$.dlg@40tude.net> <1190579805.451187.71140@d55g2000hsg.googlegroups.com> <1i8ksr774bjbj.vpmnx3c0i9qz.dlg@40tude.net> <1190646125.024072.310020@19g2000hsx.googlegroups.com> <1r9s9v6pcjifl.vp4ktk0unpd1.dlg@40tude.net> <1190753631.240548.101820@19g2000hsx.googlegroups.com> <1190843408.713838.128690@g4g2000hsf.googlegroups.com> NNTP-Posting-Host: 85.3.107.199 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190928238 31298 127.0.0.1 (27 Sep 2007 21:23:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 27 Sep 2007 21:23:58 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: o80g2000hse.googlegroups.com; posting-host=85.3.107.199; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2170 Date: 2007-09-27T14:23:58-07:00 List-Id: On 27 Wrz, 15:39, Robert A Duff wrote: > I agree with you that during construction you shouldn't dispatch to the > deeper type(s) -- i.e. the ones that can see parts of the object that > are not yet initialized. Exactly. > But I find the C++ solution less than ideal -- the programmer might well > expect to dispatch to the deeper type, and be surprised when it doesn't. Of course. I can assure you that this question is quite regular and even has its own FAQ entry: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.5 > Question: why do you want to dispatch at all during construction? I don't. And I can assure you that I don't remember any piece of code where that would actually matter to me. But Dmitry wanted to discuss completeness. ;-) > I think I remember you saying you wanted to install the object in some > global data structure. But that just means you want to create an > access-to-class-wide, and put that somewhere -- no need to dispatch. Yes, but this was taken out of some fragment of this lengthy discussion. Registration requires that T'Class is available in the base type constructor. So - even if I don't need to dispatch, I might need T'Class. > In other words, would you be happy with a rule saying you can't dispatch > during construction? I would be perfectly fine with this rule, but having this rule *and* access to T'Class are not much compatible with each other. How can you prevent me from dispatching if I already have T'Class? With runtime checks, perhaps? That's the only reasonable option (injecting artificial types is not reasonable, even if compelling for theorists), although it would mean that some type provides the interface that changes with time. I understand Dmitry's arguments against it. -- Maciej Sobczak http://www.msobczak.com/