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!p47g2000hsd.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle Date: Wed, 06 Jun 2007 07:46:47 -0700 Organization: http://groups.google.com Message-ID: <1181141207.588414.121150@p47g2000hsd.googlegroups.com> References: <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> <12ocy5k4zedug.pdeokn8ijlgx.dlg@40tude.net> NNTP-Posting-Host: 137.138.37.241 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1181141207 27196 127.0.0.1 (6 Jun 2007 14:46:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 6 Jun 2007 14:46:47 +0000 (UTC) In-Reply-To: <12ocy5k4zedug.pdeokn8ijlgx.dlg@40tude.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070601 Red Hat/1.5.0.12-0.1.slc3 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: p47g2000hsd.googlegroups.com; posting-host=137.138.37.241; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16079 Date: 2007-06-06T07:46:47-07:00 List-Id: On 6 Cze, 10:21, "Dmitry A. Kazakov" wrote: > > 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. No, you are jumping to wrong conclusions. If there exists exactly one combination (for access T'Class), then you can define a clear meaning for its implementation. In the case of access T'Class, the meaning is referential replacement. > Therefore your argument about the number of > combinations is irrelevant for any user- or compiler-generated assignment. It is very relevant. With the number of combinations in the order of O(n*n) you are not going to make it right. > what is the > *semantic* difference between access T'Class and T'Class beyond that? For example sharing. This is beyond the fundamental difference that exists between replacement and 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? Ability to share? Let's keep sharing aside for the moment, though. The real difference is that object is not a container and the "holding" doesn't work there. Objects *have* values, they don't "hold" values. Containers can "hold" objects that *have* some values themselves. And so on, up to and including the fact that access variable can *point* to an object (that *has* some value). (yes, I know - you will now ask me what is the *semantic* difference between holding and having... nevermind :-) ) Pointing and having value are different - ability to share is one of the consequences, replacement-is-not-an-assignment is another. > > 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 Yes, let's ban it too. Inout parameters should match exactly in terms of constraints (see below). > 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)? No, I don't see why it's inconsistent. The above code gives CONSTRAINT_ERROR at run-time. It's obvious and the code is just dangerous. 1. for "in" formal parameters the actual parameter can have stricter constraints (it can be subrange, it can be subclass, etc.) 2. for "out" formal parameters (and return values) the actual parameter can have looser constraints (it can be superrange, it can be a superclass, etc.) 3. for "in out" formal parameters the actual parameter must have matching constraints. Nothing new. Just a regular pre- and post-condition stuff. If this is not guaranteed at compile-time, it has to be checked at run- time, but then why not writing everything in Python. All our examples so far fell into pieces with point 3. above. > Further, > it is incompatible with specialization and generic programming on sets of > specialized types. No, there is no incompatibility. At least I don't see it (and you didn't show any). > 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 Elaborate please. > > 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. That's bad. And we are going in circles. > > 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. You have just thrown assignment together with other (real) primitive operations and then come to common conclusions. My point is that assignment is *not* a regular primitive operation. > > 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"). / conditionally_legal ("let's raise CONSTRAINT_ERROR later")? > Either you scrap the type system, by forbidding any intertype relations One of your discussion strategies is to force others to believe that they have only those choices that you arbitrariliy give them. :-) > In the middle there exists a wide > range of semi-consistent languages like C++ and, alas, Ada. Yes, that's why we have this discussion. :-) > > 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. It will dispatch with Unchecked_Deallocation on access T'Class. And, basically, this is the only way to have dispatching destructor call. But there *is* a way to have polymorphic behavior for destructor, whereas there is no way to have polymorphic constructor. > A part of the constructor of T'Class is certainly dispatching. No. There is nothing to dispatch on and with T'Class there is even nothing to overload on: function Make return Triangle; function Make return Circle; X : Object'Class := Make; -- ? -- Maciej Sobczak http://www.msobczak.com/