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 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:
> 
> > 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 predicated on subtyping and type-derivation of non-tagged types that then abuses the OO/Ada95 term "inheritance" as a proleptic anachronism, back misapplying inheritance to the entirely-different Ada83 language that clearly lacks inheritance, in both name and spirit (or primordial soup thereof).
> 
> No, it is still inheritance. Ada 83 subtype inherits operations and 
> representation of the base type. Similarly Ada 83 cloned type (type X is 
> new Y) inherits (clones) both.
> 
> > Rather, Ada83 has type derivation and subtyping, which despite the similarity of the name subtyping with OO's subclassing (made worse by C++'s & then later Java's abuse of the term class to mean a single type instead of a tree of types), subtyping in Ada83 has nothing to do with subclassing in Ada95 or any other OO language.
> 
> 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 theory, it is called ‘type extension’ not ‘inheritance’.  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 deceased.

With the precision of the mathematical term ‘type extension’ in mind, OO inheritance is extending the superclass either with additional 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 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.

Narrowing set membership is not inheritance.  For example, compile-time-enforced null exclusion is all the rage in the {Swift, Kotlin, C#} languages and 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 the address be not-an-address* in the von Neumann address space?  Mere subsets are not inheritance.

* null, in the vernacular.

Clearly, in mathematics, narrowing set membership from integers to, say, natural numbers is not inheritance.  In natural numbers, the additive identity (i.e., zero) that integers had is missing, and along with that omission any operation, theorem, or behavior that integers had that depended on the additive identity has been elided from the subtype natural numbers.  In natural numbers, the additive inverse (i.e., negative numbers) that integers had is missing, and along with that omission any operation, theorem, or behavior that integers had that depended on additive inverse has been elided from the subtype natural numbers.  Mere subsets are not inheritance.

So right there we not only see the failure of grand concepts as Liskov substitution principle, but we also see much more mundane failures for natural numbers to substitute in all of integers' interfaces to reality:  the •copying• of operations that Randy & I mention and the •reworking• of copied operations to comply with narrowed restrictions 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 & mate but instead needs batteries, then it isn't a duck; it is a hunter's decoy or a child's toy.  Inheritance = duck.  Ada's subtyping = not a duck.
 
> operation when a new type is produced from an old type by *inheriting* 
> some of the operations and representations of the old.

No, as Randy said along a different branch of this thread, the operations are not inherited; they are “copied” (i.e., taken as mere inspiration) and …
1) in subtypes:  … reworked to the narrower restrictions of the subset of the subtype (e.g., different out-of-range checks)
or
2) in derived types:  … made incompatible to be called using the parent 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 
> substitutability.

Funny that you should bring up substitutability.  In derived types there is no substitutability between parent and derived type (except in some ways of declaring parameterized-type/generic parameters).

There exists a conceptual model for examining substitutability:
Referring to
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#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 or C++ sense), there is the opportunity in language design for

a) covariance of return type (subclass returns a more-restricted T' to override superclass's function-method that returns T)

b) contravariance of parameters to routines (subclass takes a T parameter to 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 
> to the methods Ada 83 already had.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de