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!50g2000hsm.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Fri, 21 Sep 2007 14:02:06 -0700 Organization: http://groups.google.com Message-ID: <1190408526.100291.265040@50g2000hsm.googlegroups.com> References: <1190039166.449906.15070@g4g2000hsf.googlegroups.com> <1190041908.492024.263110@19g2000hsx.googlegroups.com> <1190060534.958182.51800@d55g2000hsg.googlegroups.com> <87tzptuhku.fsf@ludovic-brenta.org> <1190125656.071013.303640@22g2000hsm.googlegroups.com> <1ds7l1l7oeyrx.1cpsvrpkikour.dlg@40tude.net> <1190147965.676457.123000@d55g2000hsg.googlegroups.com> <1co37tau98gct.axsglmqh0xu9$.dlg@40tude.net> <1190213376.707449.146640@g4g2000hsf.googlegroups.com> <1fl2wnziigxfd.1fjbag2hh8sbc$.dlg@40tude.net> <1190239986.762473.204290@k79g2000hse.googlegroups.com> <1rw45b3rmvmcr$.1df4wst5oknbl$.dlg@40tude.net> <1190296353.624737.150940@y42g2000hsy.googlegroups.com> <11m13st1f92kf$.m8s6y8mc8ebk.dlg@40tude.net> <1190321119.206313.65290@57g2000hsv.googlegroups.com> NNTP-Posting-Host: 85.3.83.95 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190408526 7462 127.0.0.1 (21 Sep 2007 21:02:06 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 21 Sep 2007 21:02:06 +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: 50g2000hsm.googlegroups.com; posting-host=85.3.83.95; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2071 Date: 2007-09-21T14:02:06-07:00 List-Id: On 21 Wrz, 20:59, "Dmitry A. Kazakov" wrote: > >>>> If you say that an object of the type T1 can take values of the type T2, > >>>> such that not T1<:T2, then either: > > >>> What is T1<:T2 ? > > >> Subsumption. > > > This I can guess. What is the direction? > > Any value of T1 is also one of T2. OK. But then your initial usage of it (still cited above) is wrong in case of constructor, because the type changes in the "more specific" direction. > > No, this is strongly typed, because the type is determined > > declaratively and can be deduced without examining the value. > > If it were so, then > > class T > { > T () { f(); g(); } > void g() {} > virtual void f() {} > > }; > > should be illegal. Consider f() called in the constructor. The hidden > parameter *this of is neither of T nor of T'Class: > > It cannot be of T, because T is not yet constructed (and you don't want to > consider *this specific anyway). Not exactly. In the constructor of T, *this already has type T. Note that f() is called *after* initializing the fields (the constructor initializer list serves some purpose!). Some invariants might not be established yet, but the fields are supposedly already initialized. The invariants are not an issue - functions calling each other have to deal with this effect in general. > It is not of T'Class It is - T belongs to T'Class. > In > fact, neither g(), nor f() can be called in a true constructor. No. Both can be called, because *this has type T. Both static and dynamic. This is actually the case where virtual calls can be inlined. > BTW, this is also the reason why people calling Ada's Initialize a > constructor are wrong. Right. Ada doesn't have *any* constructors. :-) > Further, the type of *this is indeterminable, because I can explicitly call > the constructor No, you cannot. Constructor is not a function - you cannot just "call" it. (So I cut out your wrong conclusions.) > >>> Every single moment the object has one type. But the time is > >>> passing and the object's classification flows together with time. > > >> Nope, the result is another object, *because* you cannot change the type. > > > It is always the same object, on the basis of its identifier, which is > > invariant. By indentifier I take the address of the object. > > 1. You cannot take address because the object might be in cache. What is "cache"? The C++ standard says nothing about it. I can take the address of an object whenever I want. > 2. If the identifier is the only permanent property of an object then it is > exactly what one understand under untyped. Which consistently means that you just got stuck with the idea that type must be permanent. Identifier is permanent and this allows me to say that the object *persists* along the process (there is no object replacement, etc.). The type evolves during this process. > In my world people don't become whales upon fattening. At least not in one > generation. (:-)) Good. :-) What about growing up? What about getting promoted in the company? > > I *know* how the type will change without looking > > at the value. > > If you *know* it, then the actual type of the object is a class containing > the trace of all possible types the object would "take." No. There is nothing that forces me to take this view. I don't need any "actual" type, becuase the actual type is determined by the progress along the inheritance chain. > > It is completely different from assigning whatever value > > to some object and saying that it changed its type as a result of > > this. > > How is it different? Why the type can be changed upon construction, but > cannot upon assignment? Because the language recognizes the fact that construction/destruction does not happen immediately and it is a "build-up" process. Assignment is performed on the object that is already "established". > Why not to demote/promote? There are languages that support this. > In Ada terms it would change the tag. Yes. > It is difficult to implement but > consistent, under the assumption, that you do not change the type! The type > is T'Class. You can end up with Java-like Object'Class. Not much helpful. I prefer the model offered by C++, because it allows the analysis of code to be more reasonable. The objects have invariant types between the end of their constructor and the beginning of their destructor. So - a static set of objects exposes the property of static type system. It's only the process of birth and death that is difficult and it is when C++ prevents the programmer from dispatching to the function that expects some fields to be initialized while they are not. I have never found myself in a situation where that would make any difference (I don't call virtual functions from constructors), but I find the model to be more complete just by knowing that the problem can never happen. Correctness by construction, anyone? ;-) -- Maciej Sobczak http://www.msobczak.com/