comp.lang.ada
 help / color / mirror / Atom feed
From: "Dan'l Miller" <optikos@verizon.net>
Subject: Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package
Date: Thu, 31 May 2018 11:53:35 -0700 (PDT)
Date: 2018-05-31T11:53:35-07:00	[thread overview]
Message-ID: <534965d3-e494-476b-8a91-6cf9f376c020@googlegroups.com> (raw)
In-Reply-To: <pepbrv$1b3u$1@gioia.aioe.org>

On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
> > Conversely, subtyping in Ada does none of that type-extension stuff:  no
> > additional data/cardinality-of-the-members-of-the-set, no additional
> > routines/behavior, no arbitrary refinement of behavior of overridden/copied
> > routines/operations.  Instead, subtyping in Ada is strictly subjecting the
> > parent type to an additional membership-narrowing predicate, such as subset
> > in set theory.  Randy likewise spoke of membership on other branches of this
> > thread.
> 
> Untrue. Ada 83 subtyping extends the supertype (base type), because it 
> exports operations defined on the subtype to the base type. Ada 83 
> subtyping introduces an equivalent type, which is both sub- and 
> supertype of the base.

If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.  It seems that the only thing actually extended/added/supplemented in a subtype is logical conjunction (i.e., and) of another predicate.  Copied (as from an exemplar) is a better term than inherited.

Indeed, in Ada, the parent untagged type and untagged subtype need not share the same representation.  Not even representation is necessarily inherited by the subtype from the parent type.  And if representation of the subtype can differ, then this so-called inheritance of subtypes from parent types really does look more like things that do versus don't get copied from a prior exemplar via rules governing that copying-from-exemplar.

Clearly, mechanical copying-from-exemplar some things but not others is not type extension.  (Only type extension is inheritance.)  Type extension is taking the whole parent type without all this piecemeal elision-surgery (as a whole enchilada) and actually •adding• something more substantial than a predicate to it (so that now the whole enchilada now has some sauce or a side of rice and beans added to it).

Btw, I realize that Ada's _LRM_ utilizes 1,000 times the term "inherit" colloquially in the sense of OP's and Dmitry's usage.  Based on my exploration of the _LRM_, it never normatively states a definition for what inheritance is versus is not with respect to untagged types.  The _LRM_ just uses the term inherit colloquially with respect to untagged types.  In all the places where the _LRM_ colloquially uses "inherit", it could have utilized "receive" instead to emphasize the copy-from-prior-exemplar truly-intended meaning.  The OP's gotcha point is deftly dismantled by changing the colloquialism from inherit to receive.  Upon realization that "inherit" is a mere colloquialism used for convenience in the _LRM_ regarding untagged types, suddenly Ada83's receiving-from-prior-exemplar semantics regarding untagged types versus Ada95-onward's inheriting semantics regarding tagged types
1) no longer looks botched as some sort of philosophical mismatch,
2) no longer looks like a Ichbiah-versus-Taft conceptual tug of war for control of the steering wheel of the rudder of Ship Ada,
and
3) no longer has the (OP's) linguistic ability to point out gotchas where Ada83's receiving-from-prior-exemplar does not conform to expectations of modern OO inheritance.

A simple mental hygiene of not (ab)using a term (i.e., "inherit") where it shouldn't have been utilized in specifying Ada causes the entire OP's gotcha to go poof.

Conversely, over the years since the advent of the Ada9X project, the ARG did an excellent job of overtly capturing what inheritance means for tagged types:  the canonical OO definition of single inheritance without multiple dispatch with zero or more inherited interfaces.  It has none of Ada83-subtyping's piecemeal dismantling of the enchilada via rules to copy-from-exemplar some piecepart-internals of the enchilada but not others.  Why?  Because inheritance doesn't do that (but subtyping's rule-based copy-from-exemplar does).


  reply	other threads:[~2018-05-31 18:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-26 16:14 about inheritance of subtypes and entities (such as constants) related to a type in the same package Mehdi Saada
2018-05-26 16:44 ` Mehdi Saada
2018-05-29 22:07   ` Randy Brukardt
2018-05-29 22:12 ` Randy Brukardt
2018-05-30  8:13   ` Dmitry A. Kazakov
2018-05-30 19:25     ` Randy Brukardt
2018-05-30 19:45       ` Dmitry A. Kazakov
2018-05-30 19:59         ` Randy Brukardt
2018-05-31  8:44           ` Dmitry A. Kazakov
2018-05-31 22:48             ` Randy Brukardt
2018-05-31 23:39               ` Mehdi Saada
2018-06-01  2:50                 ` Shark8
2018-06-01  7:35                 ` Dmitry A. Kazakov
2018-05-30 20:53   ` Dan'l Miller
2018-05-31  8:54     ` Dmitry A. Kazakov
2018-05-31 14:29       ` Dan'l Miller
2018-05-31 14:38         ` Dan'l Miller
2018-05-31 17:37         ` Dmitry A. Kazakov
2018-05-31 18:53           ` Dan'l Miller [this message]
2018-05-31 19:59             ` Dmitry A. Kazakov
2018-05-31 21:10               ` Dan'l Miller
2018-06-01  7:56                 ` Dmitry A. Kazakov
2018-06-01 14:01                   ` Dan'l Miller
2018-06-01 15:27                     ` Dmitry A. Kazakov
2018-05-31 22:45             ` Randy Brukardt
2018-05-31 23:50               ` Dan'l Miller
2018-06-01  7:38               ` Dmitry A. Kazakov
2018-05-31 22:34     ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox