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: a07f3367d7,66fae8c862b81b17 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Received: by 10.66.86.6 with SMTP id l6mr942734paz.11.1353055707188; Fri, 16 Nov 2012 00:48:27 -0800 (PST) Path: s9ni19323pbb.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!news-hub.siol.net!news1.t-com.hr!newsfeed.CARNet.hr!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Copy vector in Ada Date: Thu, 8 Nov 2012 09:31:59 +0100 Organization: cbb software GmbH Message-ID: <582eaozv8tvd.ea9huyjml71v$.dlg@40tude.net> References: <1aWdnbcg_8-BzAzNnZ2dnUVZ_j6dnZ2d@giganews.com> <10y91ckm54l57$.8u8bbq342u1b.dlg@40tude.net> <2164bc1a-a841-46ed-bfef-4ddcae4d64f7@googlegroups.com> <1ccf2169-418c-44b7-9d5a-b684a017fbe7@googlegroups.com> <1r3lpzblxy43h$.zytp8ur1bg27$.dlg@40tude.net> <1k3sjasg1wftm$.1vlq5hm7vukhk.dlg@40tude.net> <1sinhhpvja1gx.1ue7br8bz2slq$.dlg@40tude.net> <5098f58c$0$6558$9b4e6d93@newsspool4.arcor-online.net> <509a4dfb$0$6642$9b4e6d93@newsspool2.arcor-online.net> <509aa312$0$6634$9b4e6d93@newsspool2.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Date: 2012-11-08T09:31:59+01:00 List-Id: On Wed, 07 Nov 2012 22:00:14 +0100, Yannick Duchêne (Hibou57) wrote: > Le Wed, 07 Nov 2012 21:04:27 +0100, Dmitry A. Kazakov > a écrit: > >> 1.5 Ada's specific types as related to the class-wide counterparts, e.g. >> T is a specialization of T'Class. > Both belong to a different category, can't be compared. Why do you say “T > is a specialization of T'Class”? Anything in T'Class is expected to be > predictable to behave like T, so why is T a specialization compared to > T'Class? Because: 1. T is substitutable (considered such by the compiler) for T'Class = T inherits operations of T'Class (the class-wide operations) = T <: T'Class (a subtype of T'Class). 2. Some values of T'Class have no corresponding values of T 3. All values of T have corresponding values of T'Class 2+3 = injection. 1+injection = specialization >> 2. extension = Cartesian product, Ada's tagged types > I don't see, and on the contrary, feel extensions is even where it applies > the best. > >>> The commandment can be called a basic principle in the light of >>> the substitution principle, >> >> Generalization, the kind of type deviation you are talking about, does not >> save LSP. In particular, it breaks in-operations. This is the reason why, >> for example, extensible enumerations (which would be a generalization) >> pose such a big problem. > What do you call generalization here? S is a generalization of T when S is considered substitutable (no type errors) and there exists a reverse injective mapping : T->S > Something which would be like giving > an ancestor to a type which don't have one? (not sure to understand) That is supertyping. Sub-/supertyping relation of types S and T is independent on the nature of mapping defined between values of S and T. Specialization and generalization are forms of subtyping or supertyping. >> It is important to remember that any non-trivial modification of a type >> always breaks something. There is no rule expressed in terms of type values >> which could ensure LSP. Bijection of domain sets the only mapping which >> would unconditionally satisfy the requirement of weakening pre- and >> strengthening post-conditions of all operations. > Yes, that's why using pre/post requires to be careful, to not break > anything or too much. Especially with preconditions, which may be the most > easy to forget about, due to the disjunction. Precondition of any operation shall be statically true. As simple as that. Dynamic preconditions make no sense. When precondition is static the case shall be promoted to a distinct [sub]type. But this is another discussion. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de