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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-05-31 04:29 PM, Dan'l Miller wrote:
> 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.

A new type need not to be extension to inherit from another type. 
Nothing prevents from having type "subtraction" or absolutely unrelated 
representation.

[There is a quite misunderstanding about what can be a subtype, e.g. 
LSP. It is based on well-meant alas unrealistic idea. There is nothing 
that can enforce substitutablity at the level of types.]

> 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.

Inheritance does not extend anything (e.g. in the sense of a set 
product), as the name suggests it merely inherits some interface, some 
operation implementation, some parts of representation.

> 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.

> Narrowing set membership is not inheritance.

Firstly, as I explained LSP-subtyping does not define inheritance.

Secondly, regarding substitutability your statement is wrong. Narrowing 
the set of values (specialization) warranties substitutability of 
out-operations. Consider this:

    procedure Foo (X : out Positive);

an Integer is trivially substitutable in Foo.

To summarize:

1. Generalization violates out-operations
2. Specialization violates in-operations
3. in out-operations are always violated

> Clearly, in mathematics, narrowing set membership from integers to, say, natural numbers is not inheritance.

The corresponding mathematical structure is a category, not set.

> 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.

Yes, Ada subtype /= LSP subtype, which should not worry anybody, because 
LSP subtypes are useless since no two non-trivial types can enjoy LSP 
relationship.

>> 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)

Yes, but inheritance is still present because Ada requires existence of 
a subtype for each type. So the cloning:

    type X is new Y;

First clones the representation and operation. And then inherits all 
everything in its first subtype.

> 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.

Surely you can add new operations = extend the interface. You can also 
disallow operations.

BTW, useful terms are type specialization and type generalization.

And type /= set of its values.

>> 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).

An object of Ada subtype is substitutable for its base type and 
conversely in the sense that Ada does consider this type violation. The 
behavior changes as constraints checks added to the inherited 
implementation.

> 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

Ada subtype is an equivalent type, which makes covariance and 
contravariance same.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de