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,2ff5c149712ec0eb X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!club-internet.fr!feedme-small.clubint.net!feeder1-1.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada Interfaces and the Liskov Substitution Principle 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: <1180510814.812025.251580@u30g2000hsc.googlegroups.com> <1180529642.741098.224230@q66g2000hsg.googlegroups.com> <1ljmbgesxien.syhurcvjdcd2$.dlg@40tude.net> <1180558336.041236.211560@p77g2000hsh.googlegroups.com> <1j91i6rk18kqd.4zjp36eyvps3.dlg@40tude.net> <1180619211.595952.116690@k79g2000hse.googlegroups.com> <1180704750.516171.126220@h2g2000hsg.googlegroups.com> <1r1lyrsyvr52v$.vx1t785sxb9u.dlg@40tude.net> <1180729864.936057.258970@p47g2000hsd.googlegroups.com> <1180802978.626766.128330@h2g2000hsg.googlegroups.com> <2vwm0plnu7gn.172jlansis6fm.dlg@40tude.net> <1180908240.364236.145720@g4g2000hsf.googlegroups.com> <14qx1ctt7r0kf$.on8dfqklv4jk$.dlg@40tude.net> <1180976568.313756.322280@q66g2000hsg.googlegroups.com> Date: Tue, 5 Jun 2007 10:35:52 +0200 Message-ID: <1lzp9p6pnkazp$.17gvbzz8nm6mo$.dlg@40tude.net> NNTP-Posting-Date: 05 Jun 2007 10:33:25 CEST NNTP-Posting-Host: 18ecf187.newsspool3.arcor-online.net X-Trace: DXC=ZNCH0C<03NC2:OR3:3gaE@McF=Q^Z^V3H4Fo<]lROoRAFl8W>\BH3YB@1;ZJ`1e=GBDNcfSJ;bb[EFCTGGVUmh?DLK[5LiR>kgB0?1mn1JQa5@ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16071 Date: 2007-06-05T10:33:25+02:00 List-Id: On Mon, 04 Jun 2007 10:02:48 -0700, Maciej Sobczak wrote: > On 4 Cze, 10:08, "Dmitry A. Kazakov" > wrote: > >>> I was talking about access Object'Class with Circle and Triangle being >>> both derived from Object. >> >> What is the difference between the types access T'Class and T'Class? > > Access T'Class can be reseated to point to some other object from > T'Class, even if that other object has different tag. So what? According to you that is wrong because there exist n*n possible combinations of such assignments for different tags. In what sense these combinations are different for T'Class and access T'Class? >>> We are going in circles. I say T'Class should be limited. >>> Even if T is not. >> >> If I'd say access T'Class should be limited even if T is not? > > No, access Whatever should not be unconditionally limited, otherwise > there would be little justification for its existence in the type > system. > The raison d'etre for access T is the ability to *point* - and be > *reseated*. While for T'Class it is the ability to accommodate any specific T. Where is a difference? > There are fundamental reasons for which assignment for T'Class doesn't > make sense (it would lead to objects that can change type at runtime - > you cannot get further away from Ada than that) and no matter what > magic you try, you will always hit the same wall. > Consider (again): > > procedure Swap(X : in out Object'Class; X in out Object'Class) > begin > -- whatever > end Swap; > > and then: > > declare > X : Triangle; > Y : Circle; > begin > Swap(X, Y); procedure Swap (X, Y : in out String); declare X : String := "abc"; Y : String := "klmnoprst"; begin Swap (X, Y); -- oops Why your "fundamental" reasons do not apply here? The only truly fundamental reason is that if Object was declared non-limited, then its contract is to support assignment. It is then the programmer responsibility to fulfill this contract for Triangle and Circle. Don't blame the language for your own design faults. >> Wrong. These are independent. Double dispatch controls the choice of the >> specific body, it tells nothing about how this body has to be assembled. > > Yes, but this shows that assignment in Ada cannot be modeled by any > hypothetical Assign subprogram. No analogies here. This in turn means > that introducing full double-dispatch to the discussion doesn't help > much, because implementing it would not be at all similar to anything. It is still independent. The thing is not fully decomposable into subprograms because that would require type violation, which is impossible in a typed language. Therefore some magic is needed to convert raw memory to an object and back. This is irrelevant to dispatch. And if that were a reason to forbid assignments, then *any* assignment would become illegal. Because magic is needed, assignment, construction and destruction will always be compiler-generated with some injections of user-defined subprograms at the points where necessary [sub]objects are fully constructed/destructed. This is no different from polymorphic subprograms, they are also compiler-generated. >> My approach, not shared here, is that the programmer should have more >> control over this, when he wants. > > Hm... do we agree again? :-) No, because you want to disallow assignment altogether, others want to keep it albeit sometimes inconsistent, but I want to change the language to have a way to enforce its consistency. > - constructors cannot be polymorphic, since there is no tag yet (you > might dispatch on something different, though, but this is irrelevant) There is the tag, it exists before the object and comes from the type of. A constructor (actually a part of) dispatches on the bare tag. I posted a description of my view on this some time ago: http://groups.google.com/group/comp.lang.ada/browse_thread/thread/72c34c66b38e0e05/b4b6668d530912ac?lnk=gst&q=kazakov+construction&rnum=6#b4b6668d530912ac >> In a better >> language one should be able to describe all these decompositions uniformly, >> with a higher-level mechanism of polymorphic subprograms. > > Not really. The problem is that these things work on the border of > object's life and death and for this reason they cannot be first-class > citizens in the world of polymorphic operations. The same applies to primitive operations. Dispatch happens per magic. I suppose there is a more general mechanism based on types constraints. But in any case it will be "magical." But that will be the only magic necessary. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de