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!g4g2000hsf.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle Date: Sun, 03 Jun 2007 15:04:00 -0700 Organization: http://groups.google.com Message-ID: <1180908240.364236.145720@g4g2000hsf.googlegroups.com> References: <1180452858.118039.67740@w5g2000hsg.googlegroups.com> <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> NNTP-Posting-Host: 62.233.239.129 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1180908240 15288 127.0.0.1 (3 Jun 2007 22:04:00 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 3 Jun 2007 22:04:00 +0000 (UTC) In-Reply-To: <2vwm0plnu7gn.172jlansis6fm.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: g4g2000hsf.googlegroups.com; posting-host=62.233.239.129; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16057 Date: 2007-06-03T15:04:00-07:00 List-Id: On 3 Cze, 09:09, "Dmitry A. Kazakov" wrote: > > Yes, replacement can change the tag. It's the tag of referred object > > that can change. An access variable can point to Circle and then to > > Triangle. > > No, this is illegal. At least in Ada,: access Circle and access Triangle > are different types. They cannot be assigned to each other. I was talking about access Object'Class with Circle and Triangle being both derived from Object. The access variable can point to object with different tag during its lifetime. > >>>> Ah, wouldn't replacement double dispatching? > > >>> No, it wouldn't and that's the second difference. Replacement just > >>> gets rid of the current value before the new value is refered to, > >>> which means that from the dispatching point of view this operation is > >>> simply linear on right-hand-side - it's a pure single dispatch. > > >> No, this does not work. Apart from being semantically wrong in general > >> case, it is technically wrong. > > > Why is it semantically wrong? > > Because variables of T'Class can be assigned with the values of T'Class if > T has assignment. We are going in circles. I say T'Class should be limited. Even if T is not. > >> You have to dispatch to finalize LHS. You > >> have to dispatch to re-construct it from RHS. > > > It doesn't change anything in my reasoning. Two linear dispatches > > don't magically give you double dispatch! > > Of course it does. A function of two arguments is still a function of two > arguments. Decomposability of the function into a product is irrelevant to > the issue. It dispatches in both arguments. It doesn't change anything. Think about extensibility of the system. One of the virtues of OO is the ability of the system to be reused with new types. If you have a hierarchy with N types then adding new type means you have to implement 1 finalizer and 1 cloning (if you want them, of course) and all replacement semantics in the system still works fine. In other words, you don't have to involve all other types in the hierarchy when implementing a new type. With doubly-dispatching assignment, adding new type to the same hierarchy means you have to implement N assignments for each potential situation. Or even 2*N. Now think about the hierarchy that has many branches which are extended independently... You can theoretize as long as you want and you can say (even rightly) that replacement is doubly-dispatching, but there *is* a difference between O(n+m) and O(n*m) - and this difference is what makes assignment of T'Class simply unrealistic. > Not at all. The point is: > > limited T <=> limited T'Class > > No more, no less. That's your point. Mine is T'Class should be limited. > The issue of identity / references you are trying to bring in is > irrelevant. Multiple dispatch assignment is fully applicable to wheel and > car objects. When you "replace" wheels, you could perform different tasks > depending on the types of the old and new wheels .How these tasks can be > encapsulated into one replacement action? They are not. That's the feature of replacement. This, however, brings another point - if you want to execute different assignment tasks depending on both LHS and RHS *types*, then let's extend it a bit: I want to execute different tasks depending on current *values* of both LHS and RHS. After all, if assignment is supposed to be doubly-dispatching and if it's also supposed to be no different than hypothetical Assign(X, Y), then I should be able to do this, right? Right? Unfortunately, this is completely broken in Ada. This is just another reason why doubly-dispatching assignment cannot exist. Not only it's unrealistic to implement correctly (remember the complexity), there is simply no reasonable structure to build upon. -- Maciej Sobczak http://www.msobczak.com/