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!h2g2000hsg.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle Date: Sat, 02 Jun 2007 09:49:38 -0700 Organization: http://groups.google.com Message-ID: <1180802978.626766.128330@h2g2000hsg.googlegroups.com> References: <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> <1180729864.936057.258970@p47g2000hsd.googlegroups.com> NNTP-Posting-Host: 85.3.250.179 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1180802981 25000 127.0.0.1 (2 Jun 2007 16:49:41 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 2 Jun 2007 16:49:41 +0000 (UTC) In-Reply-To: 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: h2g2000hsg.googlegroups.com; posting-host=85.3.250.179; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16051 Date: 2007-06-02T09:49:38-07:00 List-Id: On 2 Cze, 10:19, "Dmitry A. Kazakov" wrote: > > The difference is that (in Ada terms) replacement > > allows you to change the tag. Assignment cannot do this. > > Neither can. 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. This is the kind of replacement I'm talking about. But you cannot assign Triangle to Circle. > But to show this we'd need to formalize it. Briefly: types > access T and T are different types. Sure. It's just not the type of reference I'm interested in in a regular program, but the type of referred object. > The semantic of assignment of access T > is not one of T, and neither is of the assignment of T'Class! It is a typed > language, after all... Of course. That's why it is useful to distinguish them. And since we came here from the notion of strategies (in strings, but that was so long ago that it barely matters now), then replacing one strategy with another can be implemented in terms of assigning access variables. It is just not the level of abstraction I'm interested in. I don't care about access variables. What I care about is the fact that I can replace one strategy with another. I can also replace a wheel in my car but it's not assignment of wheels. Replacement and assignment are different things from the design point of view, even if replacement for T is implemented in terms of assignment for access T - that's just not the level of detail I care about. > >> 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? Consider replacing wheels in your car. > 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! In terms of implementation complexity, it is O(n+m) problem, not O(n*m). The difference comes from the fact that finalizing LHS has no influence on re-constructing from RHS. > > 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. > > It is semantically this way. There is nothing to do about it, but to scrap > either assignment or class. (We are going in circles) That's exactly what I'm talking about from the very beginning - T'Class should be limited. Is it only my impression that we actually agree? :-) > (C++ OO model is really poisoning. Don't mix types, just don't.) In what way is the C++ OO model relevant here? I'm talking about replacing wheels in my car. Twice a year I *replace* summer wheels for winter ones and the other way round. I *don't assign* them. > Take what you wish, but referential semantic is fundamentally insufficient, > in the sense that you cannot have a language without values, but only > references. Of course, I've never said that. You need both to do anything useful. > Once you had at > least one value at the end of the referential chains, you'd have to assign > (:-)) it and give a type to it. Yes. > Then > because your types algebra has classes one could create a class of. In the > end you will face the same question again: what is the assignment on the > class. All this referential stuff is just shifting subjects. No, it's not shifting subjects. It's actually what makes it possible to replace wheels in a car. Or encoding strategies in a string object. -- Maciej Sobczak http://www.msobczak.com/