Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

["Dan'l Miller" <optikos@verizon.net>]

On Friday, June 1, 2018 at 2:56:55 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-31 11:10 PM, Dan'l Miller wrote:
> > On Thursday, May 31, 2018 at 2:59:48 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-05-31 20:53, Dan'l Miller wrote:
> >>> 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.
> >>
> >> Elementary:
> >>
> >>      subtype Extension is Integer;
> >>      procedure Extended_Operation (X : Extension) is null;
> >>      X : Integer;
> >>      Y : Extension;
> >> begin
> >>      Extended_Operation (X); -- See #1
> >>      Extended_Operation (Y); -- See #2
> > 
> > There is exactly one procedure Extended_Operation, which despite its cleverly-deceptive name is not a demonstration of type extension:  We start with having a single procedure that takes X as a parameter and that is precisely where we end:  no new procedure for Y, no additional storage for Y beyond Y's Xness, no new outcome in the execution of that procedure when passed a Y (except enforcement of the [unfortunately-missing] predicate as a post-condition).
> 
> Interface was extended. Implementation details as to how many bodies 
> there will be used are irrelevant.
> 
> > Or in fewer words:  nothing about Y is X-plus-more.  There is no "more" there.
> > (not even a predicate to enforce, which would have made this example a tad juicier).
> > 
> >> The subtype Extension extends Integer with Extended_Operation, which has
> >> two separate meanings:
> >>
> >> 1. The base type Integer has now a new operation:
> >>
> >>      new Integer interface = old Integer interface + Extended_Operation
> >>
> >> 2. The subtype Extension extends inherited Integer's set of operations:
> >>
> >>      Extended interface = old Integer interface + Extended_Operation
> > 
> > Invoking the same subprogram
> 
> Same to what? The interface of Integer as defined by the standard does 
> not have Extended_Operation. How is it same?

(How clever that you snipped my already-existing answer to your question at precisely the word where it becomes the inconvenient answer.  The elided original answer is restored as the next quotation below.)

Extended_Operation is merely invoked twice.  Extended_Operation is •the same• as itself, regardless if passed X as an argument or passed Y as an argument.

If Extended_Operation were named GiveTheKidABath instead, it would be obvious to all readers that giving two kids {X, Y} a bath, does not extend Y by growth and does not extend the size of the family by birthing more babies.  Nothing whatsoever was extended by invoking Extended_Operation against both X and Y.  Despite its cleverly-deceptive name (and despite invoking that subprogram twice), there is no extension whatsoever in Y beyond Y's Xness.  If Y was declared with a predicate, then Y would actually demonstrate some contraction of Xness.  Contraction (smaller domain) is not extension (bigger size or bigger mission) either.

> Invoking the same subprogram again (even with a potentially-created temporary) is not adding
> something to X to make a bigger-better Y.  Type extension needs some sort of •extension• whatsoever. 
> Extension whatsoever needs something extant to have been added/supplemented/made-more-of-it,
> e.g., additional storage, additional subprograms (not the same one invoked twice), additional something
> quantifiable or something-tangible beyond mere narrowed post-condition range enforcement and
> beyond mere temporary creation iff Y's representation were to differ from X's (due to some range
> restriction predicate, which was unfortunately omitted here). 

Attention maintainers:  the inability to determine the correct meaning of my “Invoking the same subprogram again” in the context of
>>      Extended_Operation (X); -- See #1 
>>      Extended_Operation (Y); -- See #2 
is clearly failing the Turing test due to A-is-A or A-is-itself not being understood at all.  Time flies like an arrow, but fruit flies like a banana, eh?

I think that this is crystal-clear evidence of what is going on here.