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!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor.de!newsspool1.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: <1180124867.710641.176330@k79g2000hse.googlegroups.com> <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> Date: Fri, 1 Jun 2007 16:53:20 +0200 Message-ID: <1r1lyrsyvr52v$.vx1t785sxb9u.dlg@40tude.net> NNTP-Posting-Date: 01 Jun 2007 16:51:00 CEST NNTP-Posting-Host: f4cf3e9e.newsspool2.arcor-online.net X-Trace: DXC=EbT;HI5>;;4lIh70@7enW;^6ZC`4IXm65S@:3>?9QWiiWeRZC= X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16029 Date: 2007-06-01T16:51:00+02:00 List-Id: On Fri, 01 Jun 2007 06:32:30 -0700, Maciej Sobczak wrote: > On 1 Cze, 09:29, "Dmitry A. Kazakov" > wrote: > >> You are trying to invent some alternative meaning for class-wide. > > Not really. > There is a difference between this: > > X : T'Class := Y; > > and this: > > X := Y; -- with X, Y : T'Class; > > The difference is coming from the fact that T'Class gets bound at > initialization only and cannot change its binding (tag for you) later > on (X cannot change the actual type). This is a constraint. It does not change the meaning of T'Class. The pragmatic argument is that this constraint cannot be checked at compile time, so you cannot make it illegal. The formal argument is that values of T'Class are supposed to mimic ones of the specific types from class T (generic programming etc). So IF T (the root type of the class) has a primitive subprogram F then T'Class shall act on it. This is the definition of class and primitive subprograms of. In particular, if T has ":=" that is equivalent to polymorphic ":=" being defined on T'Class. There is no obvious way to change this, otherwise than by providing another definition of T'Class and class T and primitive subprograms of 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. [Contravariant operations of T'Class have been discussed earlier] > In other words, X can become equivalent to Y by initialization, but > not by assignment. The latter is already too late - you might be > assigning Triangles to Circles. > This is what makes T'Class different from T. No, it makes different construction from example and assignment. They are indeed different, however one could be defined in terms of another. But this by no means influences the semantics of T'Class. >>> You don't need to assign it. It is enough if you can replace it. >> >> Care to explain difference? > > 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." Ah, wouldn't replacement double dispatching? Then let "assignment" := "replacement," and we are back where we started from. (:-)) > 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. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de