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,2ff5c149712ec0eb X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!w5g2000hsg.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle Date: Tue, 05 Jun 2007 15:12:29 -0700 Organization: http://groups.google.com Message-ID: <1181081549.890902.141600@w5g2000hsg.googlegroups.com> References: <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> <1lzp9p6pnkazp$.17gvbzz8nm6mo$.dlg@40tude.net> NNTP-Posting-Host: 85.0.249.91 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1181081550 3718 127.0.0.1 (5 Jun 2007 22:12:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 5 Jun 2007 22:12:30 +0000 (UTC) In-Reply-To: <1lzp9p6pnkazp$.17gvbzz8nm6mo$.dlg@40tude.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: w5g2000hsg.googlegroups.com; posting-host=85.0.249.91; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16074 Date: 2007-06-05T15:12:29-07:00 List-Id: On 5 Cze, 10:35, "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? In the sense that access T'Class has only one combination to cover and since access is a fundamental type, this is handled by the language. You don't have to do anything to make assignment for access T'Class work! > > 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? In assignment. (We are really going in circles.) > procedure Swap (X, Y : in out String); > > declare > X : String := "abc"; > Y : String := "klmnoprst"; > begin > Swap (X, Y); > -- oops OK, even better. Let's ban assignment for all unconstrained types. :-) > Why your "fundamental" reasons do not apply here? The "fundamental" reasons apply here as well. The problem is of a general nature. > 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. No. Regular objects are declared as Triangles and Circles (and these types may have reasonable assignments - after all, assigning one Triangle to another makes sense). The problem is when you declare something as T'Class. T'Class /= T and this is one of the things that make them different. I know that it shakes part of the concept of a class. But you have the same problem with unconstrained types. They might not support all operations of their constrained equivalents. > > - 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 don't agree on this. X : T; Y : T'Class := Whatever; Do_Something(X); -- (1) Do_Something(Y); -- (2) Which of the two above are dispatching (assume Do_Something is primitive)? My understanding of the concepts is that only (2) is a dispatching call, (1) is not. The constructors are non-dispatching, no matter how much of the "fetus object" is there when the call is made. Even if there is a tag, it's known statically and then this is just overloading, not polymorphism in the OO sense. > > 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. Still, there is a difference between T and T'Class. As far as I understand it, constructor calls are not dispatching. -- Maciej Sobczak http://www.msobczak.com/