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: Fri, 01 Jun 2007 13:31:04 -0700 Organization: http://groups.google.com Message-ID: <1180729864.936057.258970@p47g2000hsd.googlegroups.com> References: <1k165n4jwxna3$.1mpx49xvcrc0z$.dlg@40tude.net> <1180254636.632499.3340@o5g2000hsb.googlegroups.com> <1p717twnydnre$.1j6izygvqo832.dlg@40tude.net> <1180425803.422075.100090@o5g2000hsb.googlegroups.com> <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> NNTP-Posting-Host: 85.3.222.100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1180729865 17239 127.0.0.1 (1 Jun 2007 20:31:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 1 Jun 2007 20:31:05 +0000 (UTC) In-Reply-To: <1r1lyrsyvr52v$.vx1t785sxb9u.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: p47g2000hsd.googlegroups.com; posting-host=85.3.222.100; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16038 Date: 2007-06-01T13:31:04-07:00 List-Id: On 1 Cze, 16:53, "Dmitry A. Kazakov" wrote: > or claiming that there is a semantic difference between X:=Y > and Assign(X,Y). I don't want a language with magical, semantically > non-decomposable assignments. You have them at the level of fundamental types. You can treat X:=Y and Assign(X,Y) to be equivalent for *your* T (and if you have complete control over overloading of assignment then that might be actually the case), but at some level of detail they have to be implemented in terms of *non-decomposable* assignments of fundamental types anyway. Now, the difference between T and T'Class is that operations with T can be statically decomposed down to this non- decomposable bricks. With T'Class it's just impossible to do this mechanically and it's unrealistic to expect it from the programmer for any non-trivial hierarchy. > > You can replace a Circle with a Triangle but you better not try to > > assign them. > > This is not an explanation. Show a semantic difference between changing a > name binding from one value to another by A) "replacement" and B) > "assignment." No problem. Replacement is when you just stop refering to X and start refering to Y (or its clone if the objects are mutable). Assignment is when you decompose down to real, hard-core-metal-and-concrete ':=' on fundamental types. The difference is that (in Ada terms) replacement allows you to change the tag. Assignment cannot do this. > 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. Assignment has to be '2D' with both axes, or O(n2) in terms of implementation complexity. It has to be double-dispatching to make any sense and this is unrealistic implementation-wise. That's why T'Class, even though very interesting from the language construction point of view, cannot entirely include all functionality of access variable to T'Class (or pointer to base class in C++ jargon). > Then let "assignment" := > "replacement," Do you mean: - let's replace assignment by replacement, or - let's assign replacement to assignment? ;-) > > No, hierarchies and values don't go together. I might lack the > > formalism to prove it, but my observations are confirming: I've never > > seen it in the wild. > > Lacking formalism is not an excuse, it is an indictment. (:-)) I don't really think I will ever convince you, but this discussion is an interesting exercise anyway. ;-) T'Class should be limited. -- Maciej Sobczak http://www.msobczak.com/