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,dbcfe2b0a74da57e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!tudelft.nl!txtfeed2.tudelft.nl!amsnews11.chello.com!newsfeed01.chello.at!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Inherited Methods and such Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.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: <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> Date: Fri, 21 Sep 2007 20:59:56 +0200 Message-ID: NNTP-Posting-Date: 21 Sep 2007 20:58:45 CEST NNTP-Posting-Host: 18b12835.newsspool1.arcor-online.net X-Trace: DXC=`@n0MdIAME_5]7JFOE X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:2069 Date: 2007-09-21T20:58:45+02:00 List-Id: On Thu, 20 Sep 2007 13:45:19 -0700, Maciej Sobczak wrote: > On 20 Wrz, 18:22, "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. > 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). It is not of T'Class because T and all possible derived from it types shall be constructed before T'Class. In fact, neither g(), nor f() can be called in a true constructor. BTW, this is also the reason why people calling Ada's Initialize a constructor are wrong. Initialize is not a constructor of either T or T'Class. Further, the type of *this is indeterminable, because I can explicitly call the constructor at any stage of filling the dispatching table, the effect will depend on the table. So either you commit *this to a mutating specific type T or to static polymorphic type T'Class. But in either case the contract is violated in T::T(). >>> 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. 2. If the identifier is the only permanent property of an object then it is exactly what one understand under untyped. The only behavior you can associate with the object is its identifier. >> Even if you cast and per chance the address of the result is same (why >> should anybody care?), it is a different object. > > No, it's the same object. It's just fattening. > Unless in your world people change their identity after fattening. :-) In my world people don't become whales upon fattening. At least not in one generation. (:-)) >> Otherwise, you would have >> to drop the concept of single type and go untyped. > > If you limit yourself to these two options only, it's your limitation, > not mine. > I see a place for dynamically changing types. It is *single* in any > given moment. > It is still typed, because it is determined a priori, > not by actual value. See above. > 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." In this case the object is polymorphic and has exactly one type. The construction is the following: T={t1,t2,t3} S={s1,s2} Now if you know that X is either T or S. Then the type of X is class {T,S}= { (T,t1), (T,t2), (T,t3), (S,s1), (S,s2) } X does not mutate and its values are neither of T or of S, we cannot do that without breaking strong typing. > 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? Why not to demote/promote? In Ada terms it would change the tag. It is difficult to implement but consistent, under the assumption, that you do not change the type! The type is T'Class. In the example above: X : class {T,S} := (T,t1); begin X := (T,t2); X := (S,s1); -- The type is not changed! The contract of X is invariantly class {T,S}. The so-called specific type of X changes, but it is not the true type of. It is the type of the second component of its value. The true type is class {T,S}. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de