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 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:d405:: with SMTP id l5-v6mr3388242iog.70.1527776943272; Thu, 31 May 2018 07:29:03 -0700 (PDT) X-Received: by 2002:a9d:604f:: with SMTP id v15-v6mr293430otj.11.1527776943088; Thu, 31 May 2018 07:29:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!2.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!u74-v6no903707itb.0!news-out.google.com!b185-v6ni1018itb.0!nntp.google.com!v8-v6no898913itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 31 May 2018 07:29:02 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package From: "Dan'l Miller" Injection-Date: Thu, 31 May 2018 14:29:03 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 7971 X-Received-Body-CRC: 4242732815 Xref: reader02.eternal-september.org comp.lang.ada:52811 Date: 2018-05-31T07:29:02-07:00 List-Id: On Thursday, May 31, 2018 at 3:54:22 AM UTC-5, Dmitry A. Kazakov wrote: > On 2018-05-30 10:53 PM, Dan'l Miller wrote: >=20 > > Yes, I realize that this thread is speaking colloquially in retrospect = about Ada83 features as primordial pre-OO. But the OP's entire topic is pr= edicated on subtyping and type-derivation of non-tagged types that then abu= ses the OO/Ada95 term "inheritance" as a proleptic anachronism, back misapp= lying inheritance to the entirely-different Ada83 language that clearly lac= ks inheritance, in both name and spirit (or primordial soup thereof). >=20 > No, it is still inheritance. Ada 83 subtype inherits operations and=20 > representation of the base type. Similarly Ada 83 cloned type (type X is= =20 > new Y) inherits (clones) both. >=20 > > Rather, Ada83 has type derivation and subtyping, which despite the simi= larity of the name subtyping with OO's subclassing (made worse by C++'s &= =C2=A0then later Java's abuse of the term class to mean a single type inste= ad of a tree of types), subtyping in Ada83 has nothing to do with subclassi= ng in Ada95 or any other OO=C2=A0language. >=20 > Yes, but these are names for the same concept of a types algebra Funny that you should appeal to type algebra in type theory. In type theor= y, it is called =E2=80=98type extension=E2=80=99 not =E2=80=98inheritance= =E2=80=99. Only us rubes over here in tech-world, use the term inheritance= as if the subclass is the heir and the superclass is the estate of the dec= eased. With the precision of the mathematical term =E2=80=98type extension=E2=80= =99 in mind, OO inheritance is extending the superclass either with additio= nal data or additional routines or refined behavior of overridden routines.= Conversely, subtyping in Ada does none of that type-extension stuff: no = additional data/cardinality-of-the-members-of-the-set, no additional routin= es/behavior, no arbitrary refinement of behavior of overridden/copied routi= nes/operations. Instead, subtyping in Ada is strictly subjecting the paren= t type to an additional membership-narrowing predicate, such as subset in s= et theory. Randy likewise spoke of membership on other branches of this th= read. Narrowing set membership is not inheritance. For example, compile-time-enf= orced null exclusion is all the rage in the {Swift, Kotlin, C#} languages a= nd their eras of language definition. Clearly, null exclusion is a special= case of Ada's subtying applied to the topic of von Neumann addresses (e.g.= , pointers, references, access, or whatever is the jargon du jour): can th= e address be not-an-address* in the von Neumann address space? Mere subset= s are not inheritance. * null, in the vernacular. Clearly, in mathematics, narrowing set membership from integers to, say, na= tural numbers is not inheritance. In natural numbers, the additive identit= y (i.e., zero) that integers had is missing, and along with that omission a= ny operation, theorem, or behavior that integers had that depended on the a= dditive identity has been elided from the subtype natural numbers. In natu= ral numbers, the additive inverse (i.e., negative numbers) that integers ha= d is missing, and along with that omission any operation, theorem, or behav= ior that integers had that depended on additive inverse has been elided fro= m the subtype natural numbers. Mere subsets are not inheritance. So right there we not only see the failure of grand concepts as Liskov subs= titution principle, but we also see much more mundane failures for natural = numbers to substitute in all of integers' interfaces to reality: the =E2= =80=A2copying=E2=80=A2 of operations that Randy & I mention and the =E2=80= =A2reworking=E2=80=A2 of copied operations to comply with narrowed restrict= ions doesn't even happen at all for numerous characteristics of the parent = type. They are simply not copied at all to the narrowed-membership subtype= . There is no analogue of that not-there-at-all elision of characteristics= of the parent type in inheritance. When it looks like a duck and quacks like a duck but can't hatch & eat & ma= te but instead needs batteries, then it isn't a duck; it is a hunter's deco= y or a child's toy. Inheritance =3D duck. Ada's subtyping =3D not a duck. =20 > operation when a new type is produced from an old type by *inheriting*=20 > some of the operations and representations of the old. No, as Randy said along a different branch of this thread, the operations a= re not inherited; they are =E2=80=9Ccopied=E2=80=9D (i.e., taken as mere in= spiration) and =E2=80=A6 1) in subtypes: =E2=80=A6 reworked to the narrower restrictions of the sub= set of the subtype (e.g., different out-of-range checks) or 2) in derived types: =E2=80=A6 made incompatible to be called using the pa= rent type and vice versa when appearing as parameters to routines. Neither #1 nor #2 are properties of type extension. > Different are the ways of inheritance and methods of achieving=20 > substitutability. Funny that you should bring up substitutability. In derived types there is= no substitutability between parent and derived type (except in some ways o= f declaring parameterized-type/generic parameters). There exists a conceptual model for examining substitutability: Referring to https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_scien= ce)#Inheritance_in_object-oriented_languages where T' is a derived type of T, there is no invariance, no covariance, and= no contravariance because T' is not substitutable for T, hence T' did not = inherit from T. where T' is a subtype of T in the Ada sense (but not speaking of the Java o= r C++ sense), there is the opportunity in language design for a) covariance of return type (subclass returns a more-restricted T' to over= ride superclass's function-method that returns T) b) contravariance of parameters to routines (subclass takes a T parameter t= o override a superclass's method that takes a more-restricted T' parameter) c) [unwisely, as in Eiffel] covariance of parameters to routines (subclass = takes a more-restricted T' parameter to override a superclass's method that= takes a T parameter) > Ada 95 introduced a new (for Ada) method in addition=20 > to the methods Ada 83 already had. >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de