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!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder.ecngs.de!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool4.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: <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> <1181081549.890902.141600@w5g2000hsg.googlegroups.com> Date: Wed, 6 Jun 2007 10:21:41 +0200 Message-ID: <12ocy5k4zedug.pdeokn8ijlgx.dlg@40tude.net> NNTP-Posting-Date: 06 Jun 2007 10:19:12 CEST NNTP-Posting-Host: db2247a2.newsspool4.arcor-online.net X-Trace: DXC=]nWCk_N@M87RadXUBHgFh34IUKkg27l1gY56`1:6 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16076 Date: 2007-06-06T10:19:12+02:00 List-Id: On Tue, 05 Jun 2007 15:12:29 -0700, Maciej Sobczak wrote: > 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! Hence you agree that when assignment is defined then it is no matter how many combination of exists. Therefore your argument about the number of combinations is irrelevant for any user- or compiler-generated assignment. In our earlier discussion I assumed this obvious, as it follows from separation of implementation and interface. Anyway, now, when the implementation is finally left to the problem domain, what is the *semantic* difference between access T'Class and T'Class beyond that? >>> 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. Nope, you cannot say that the difference is in assignment, because now we are talking about "ability to point" and "ability to hold." What makes "point" different to "hold", semantically I mean? >> 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. :-) My congratulations! But that's not all: procedure Swap (X, Y : in out Integer); declare X : Positive := 1; Y : Integer := -1; begin Swap (X, Y); -- oops I hope you see now, why your proposal is inconsistent with any type system with constrained [sub]types (classes is just a specific case of)? Further, it is incompatible with specialization and generic programming on sets of specialized types. It can be easily shown, that it is also incompatible with generalization and in the end with generic programming on any non-trivial sets of types. >> Why your "fundamental" reasons do not apply here? > > The "fundamental" reasons apply here as well. The problem is of a > general nature. Huh, speaking of general natures, the problem is a misconception shared by LSP-ers. The issue can be summarized in three lines: 1. Specialization breaks all out-methods of the base type 2. Generalization breaks all in-.methods of the base type 3. Variation breaks everything The rest is consequences. This cannot be fixed and need not to. >> 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. Wrong. Assignment is a primitive operation <=> it is defined on T'Class. Specific assignments are irrelevant here. > 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. Yep, it demolishes class and primitive operations of. > But you have the same problem with unconstrained types. They might not > support all operations of their constrained equivalents. What does it mean "not support"? You have to translate this into illegal ("type error") / legal ("no type error"). See above, there is no way out. Either you scrap the type system, by forbidding any intertype relations or you have to live with the cross cases. In the middle there exists a wide range of semi-consistent languages like C++ and, alas, Ada. >>> - 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)? So? Following your argument destructor of X isn't dispatching either, because it will not dispatch in this piece of code. A part of the constructor of T'Class is certainly dispatching. The constructor of T is specific for T. This makes constructor a primitive operation. On the other hand, constructors are composed by extension, which makes them class-wide operations as well (you have to construct T'Class for a specific S derived from T). This controversy is the reason why constructors aren't easy to get right. The idea of my proposal was to make it typed and factor out specific and class-wide parts a constructors as user-defined subprograms. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de