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!q66g2000hsg.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle Date: Mon, 04 Jun 2007 10:02:48 -0700 Organization: http://groups.google.com Message-ID: <1180976568.313756.322280@q66g2000hsg.googlegroups.com> References: <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> <1180908240.364236.145720@g4g2000hsf.googlegroups.com> <14qx1ctt7r0kf$.on8dfqklv4jk$.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 1180976568 6573 127.0.0.1 (4 Jun 2007 17:02:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 4 Jun 2007 17:02:48 +0000 (UTC) In-Reply-To: <14qx1ctt7r0kf$.on8dfqklv4jk$.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: q66g2000hsg.googlegroups.com; posting-host=62.233.239.129; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16064 Date: 2007-06-04T10:02:48-07:00 List-Id: On 4 Cze, 10:08, "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. Thanks to this, access T'Class can be used to provide replacement semantics for T'Class, where assignment wouldn't work. I believe I get the Ada basics right. > > We are going in circles. I say T'Class should be limited. > > Even if T is not. > > If I'd say access T'Class should be limited even if T is not? 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*. Of course, there is a place for constant access Whatever, but this is another story. > > 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. > > No, that makes it unrealistic to manage this complexity using crude > patterns instead of a consistent approach. The problem is here, the choice > is between language support and manual cascaded case-statements. No, there is no choice whatsoever. There is nothing that cascaded case- statements can buy you that you couldn't do with dispatch (except maybe static coverage tests - but these don't exist in open hierarchies). There are fundamental reasons for which assignment for T'Class doesn't make sense (it would lead to objects that can change type at runtime - you cannot get further away from Ada than that) and no matter what magic you try, you will always hit the same wall. Consider (again): procedure Swap(X : in out Object'Class; X in out Object'Class) begin -- whatever end Swap; and then: declare X : Triangle; Y : Circle; begin Swap(X, Y); -- oops end; It does not matter what is inside Swap. Double-dispatch, cascading case, unchecked magic, whatever. These are all low-level details of something that just doesn't fly anyway. > > 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? > > Wrong. These are independent. Double dispatch controls the choice of the > specific body, it tells nothing about how this body has to be assembled. Yes, but this shows that assignment in Ada cannot be modeled by any hypothetical Assign subprogram. No analogies here. This in turn means that introducing full double-dispatch to the discussion doesn't help much, because implementing it would not be at all similar to anything. > In some cases you might really want LHS being finalized > before the overridden part of the assignment, like when it holds an > expensive resource. 1. In *some* cases. In those cases I can take this decision on my own. 2. Actually, in those cases when LHS keeps expensive resource I would very much welcome the ability to reuse it, if possible. Consider: declare S1 : My_String_Type := "abcd"; S2 : My_String_Type := "xyz"; begin S1 := S2; end; No need to finalize LHS here (and reallocate again to hold a copy of RHS). Other examples abound. Sorry to say this, but when I see things like *this*, I have an impression that Ada is SbyC (Slow by Construction - you can quote me :-) ). This is *obvious* optimization opportunity! But that was aside, nothing about T'Class being limited. > My approach, not shared here, is that the programmer should have more > control over this, when he wants. Hm... do we agree again? :-) > The constructors, destructors, > assignments and aggregates are all polymorphic subroutines composed > differently from normal primitive and class-wide operations. Agreed with exceptions: - constructors cannot be polymorphic, since there is no tag yet (you might dispatch on something different, though, but this is irrelevant) - assignments are banned anyway ;-) Destructors are obviously polymorphic. > In a better > language one should be able to describe all these decompositions uniformly, > with a higher-level mechanism of polymorphic subprograms. Not really. The problem is that these things work on the border of object's life and death and for this reason they cannot be first-class citizens in the world of polymorphic operations. > > Unfortunately, this is completely broken in Ada. > > It is not broken, it does not exist. Adjust is not an assignment, it is > hack to provide functionality without much rethinking. Hacks make things broken. Every language has its hacks, but this one is just too fundamental to be easily forgiven. ;-) -- Maciej Sobczak http://www.msobczak.com/