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!194.134.4.77.MISMATCH!news2.euro.net!newsfeed.freenet.de!news.albasani.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool4.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> Date: Thu, 20 Sep 2007 18:22:42 +0200 Message-ID: <11m13st1f92kf$.m8s6y8mc8ebk.dlg@40tude.net> NNTP-Posting-Date: 20 Sep 2007 18:21:33 CEST NNTP-Posting-Host: 2d3aa6cd.newsspool3.arcor-online.net X-Trace: DXC=BEdIKGA^DoME4ZB2flKORAMcF=Q^Z^V3H4Fo<]lROoRA^;5]aA^R6>Bgf1^IVXE\jH[6LHn;2LCVN[ On Thu, 20 Sep 2007 06:52:33 -0700, Maciej Sobczak wrote: > On 20 Wrz, 10:12, "Dmitry A. Kazakov" > wrote: > >>> My expectations are different during the lifetime of the object. Hence >>> - the behavior that I expect is time-variant. Hence - the type changes >>> over time. End of story. >> >> 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. > Whatever it is, your assumptions are still wrong. > There is no point in discussing the concept of "taking the value" > here, because the value is meaningful in the context of its type only. Even better, so objects have no values, but many types... [...] > There is no such thing as object of type T taking new value, nor the > value changing type. Neither value nor type is constant here. They > flow together as the object is progressively constructed/destructed > and every single moment in time the object has a valid value of *some* > type. Right, this is called untyped. The rest is handwaving. >> Huh, let us take this and consider the predicate "dynamically". Then: >> >> forall x of T, dynamically(x) > [...] > >> For this >> reason any object has exactly one type. No more, no less. > > Yes. 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. Even if you cast and per chance the address of the result is same (why should anybody care?), it is a different object. Otherwise, you would have to drop the concept of single type and go untyped. (BTW classification. "Type" is another word for "classification." Types classify sets of values) > This is not true in C++. It is no matter how C++, Ada or PHP would define it. Because it is a model that describes what is going on in the given language. Here the programming language is just an object language, a subject. A model is only wrong when it describes things incorrectly. If C++ calls type "class," that does not bother me, naming conventions do not influence the model. Ada subtypes and Liskov subtypes as known in CS have nothing in common either. So what? The model I am talking about can describe C++, though it cannot describe it in a way that some nice and desirable constraints, like object-type bijection, statically determinable types, statically comparable types, would necessarily hold. This classifies C++ as weakly typed, if not untyped. Is that surprising? The choice of a model is a question of personal preferences. I don't like models where an object has many types but no values. It is counterintuitive, and I believe inconsistent. Provided, somebody would take care and tried to formalize such a mess. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de