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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham 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.79.233 with SMTP id m9mr2464918pax.37.1352353230221; Wed, 07 Nov 2012 21:40:30 -0800 (PST) From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Copy vector in Ada Date: Tue, 06 Nov 2012 03:17:07 +0100 Organization: Ada @ Home Message-ID: References: <1aWdnbcg_8-BzAzNnZ2dnUVZ_j6dnZ2d@giganews.com> <5460fdc7-5490-4889-b771-67cc281c10c5@googlegroups.com> <6260a796-83c4-4ce5-88cb-8249846bc035@googlegroups.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> NNTP-Posting-Host: 80Danr8LSk+wZCZOQUcJiA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.02 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Path: 6ni68208pbd.1!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.mccarragher.com!news.grnet.gr!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!rt.uk.eu.org!aioe.org!.POSTED!not-for-mail X-Received-Bytes: 8957 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-11-06T03:17:07+01:00 List-Id: Le Tue, 06 Nov 2012 00:58:53 +0100, Hibou57 (Yannick Duch=C3=AAne) = a =C3=A9crit: > Le mardi 6 novembre 2012 00:45:21 UTC+1, Shark8 a =C3=A9crit : >> On Monday, November 5, 2012 2:34:40 PM UTC-7, Hibou57 (Yannick Duch=C3= =AAne) = >> wrote: > > a derivation hierarchy. That's like a subtype, not a type = as = >> a member of a > class (a subtype of Integer is not a member of a = >> fictitious Integer class). But it is, isn't it? Universal_Integer =E2= =8A=83 = >> Integer =E2=8A=83 Positive. Therefore, Universal_Integer =E2=8A=83 Po= sitive. Universal = >> integers are a fictitious class of integers and Positive is a subtype= = >> of Integer. > > Well try, but I pretty sure it's a wrong interpretation. Inclusion = > relation in a type hierarchy, is precely the opposite way. A type = > defines a set of possible values or states, a class is a set, but not = = > the same set. Positives indeed belongs to the set of values specified = by = > an Integer, but a Positive does not belong to the set fictitious set o= f = > class whose root type would be Integer. > > And no, universal integer does not define a class, but a set of values= . > > More on "Inclusion relation in a type hierarchy, is precely the opposi= te = > way": a derived type has to cover a base type, and will probably do = > more, but in anyway, not less. > > Classes and values do not belongs to the same kind of sets. Back to tell more, and I hop, clearer. First a summary, then later more details: there's a difference between = reuse inheritance and interface inheritance; both must not be confused = (unfortunately, it often is), then (as already said) there's a set of = values and a set of types; here also, both must not be confused = (unfortunately, due to the use of inheritance for reuse, this confusion = = often occurs too). Personally, I see types only via their interface, so to me the proper = inheritance is the interface inheritance. The following is not personal = = opinion: a type is defined by a set of value and a set of operations, wi= th = properties. A derived type must provide at least the same set of = operations, and in the programming area, it must provide all, even the = ones which could be derived from provided ones. Ex. even if the equality= = may be derived from some others primitives, if it was specified in a = parent interface it will have to be provided (software design and math = analysis differs a bit here, software design is a bit more strict, as it= = does not automatically derives things which could be). Then, with = operations, comes two things: domains and codomains (also known as targe= t = domain). For each operation of a derived type, the domain must be a = superset (at worst, an equal set) of the domain of the corresponding = operation in the parent. Inversely, the codomain of an operation must be= a = subset (at worst an equal set). Hence, things cannot be described as set= = ownership, except for the set of operations, and the set of values is no= t = enough for a caracterisation. You have: a set of values, a set of = operations, operation's domain sets, and operation's codomain sets. Now, when you create a =E2=80=9Cderived=E2=80=9D type from Integer, you = are restricting = both the domain and the codomain, which makes it anything you would want= , = but not an interface derivation. That's OK with the codomain which becom= e = a subset, but the domain too becomes a subset (domain and codomain are = covariant in this case), which is wrong for an interface derivation. For a numeric type, say `My_Integer_Type`, to be really derived from = `Integer`, as an example, the signature for the addition should be defin= ed = as: function "+" (Left, Right: Integer) return My_Integer_Type; This is actually not the case, and you get instead: function "+" (Left, Right: My_Integer_Type) return My_Integer_Type;= Conclusion: `My_Integer_Type` does not belong to anything like an = `Integer'Class` (which does not exist in Ada, and Ada is right with). If there was an universal_integer class to which `Integer` would belong,= = then we should have something like: function "+" (Left, Right: universal_integer) return Integer; which does not exist as=E2=80=91is (except for intermediate results). So, what's this, if not a proper type derivation (interface inheritance)= ? = That's a reuse inheritance. Strictly speaking, reuse inheritance should = = never appears, that's a dangerous practice (from a design point of view)= , = and composition should be used instead, defining a fully new root type a= nd = root class in the while. Ada is right with its notion of subtype, like in: subtype My_Integer_Type is Integer range -10 .. 10; But Ada is a bit wrong (personal opinion) with this: type My_Integer_Type is new Integer range -10 .. 10; It would better be instead: subtype My_Integer_Type is new Integer range -10 .. 10; When you do: type My_Integer_Type is new Integer range -10 .. 10; you do this just to reuse the Integer type's physical representation and= = built=E2=80=91in primitives, not to define a type belonging to an Intege= r class. I said the inclusion relation you gave is the reverse of that of the cla= ss = relation, here is why: if there is a proper type derivation, that's not = = Integer which derives from universal_integer, but the opposite, = universal_integer which derives from Integer. You can check if you try t= o = apply the rules of a valid type/interface derivation. The domain of = operation of universal_integer is a superset of that of Integer, the = codomain is not a subset, but equals the same codomain when the input = belongs to the same domain, so that universal_integer could belong to a = = class defined by Integer; not the other way. Similarly, Integer belongs = to = the class of Positive or any subtype of Positive. With the numeric type = = hierarchy, the real type hierarchy is head down feet up: universal_integ= er = inherits the interface of all Positive subtypes and all Integer subtypes= . All of this also explains why a subtype is not the same as a type = derivation (and is even the opposite), and Ada is nice to provide this = distinction (I know no other language with this, even SML don't have = this). At least, the existence of a notion of subtype, makes things like= = constants, parameter modes and others, describable in the own terms of = Ada, properly (Dmitry gave a good example). -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity