Re: A bad counterintuitive behaviour of Ada about OO

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

On Fri, 08 Aug 2014 13:34:36 -0600, Shark8 wrote:

> On 08-Aug-14 05:20, Dmitry A. Kazakov wrote:
>> And they [subtypes] break in-operations. As an example consider:
>>
>>     X : Integer := -1;
>>
>> Now substitute Positive for Integer.
> 
> That's going the wrong way.
> You're narrowing the set when you move to the subtype, so obviously not 
> all values will be present; this is a Good Thing.

No idea what you mean. It is not substitutable. Period.

[...]
>      Subtype Social_Security_Number is String(1..9)
>      with Dynamic_Predicate =>
>        (for all C of Social_Security_Number => C in Digit);
[...]

> We *don't* want to substitute STRING for Social_Security_Number or

You substitute Social_Security_Number for String when you inherit String
operations, like S'Length.

You substitute String for Social_Security_Number when you export
Social_Security_Number operations to String. Ada subtypes allows that too.
 
>> Subsetting means nothing to subtyping and both very little to
>> substitutability. All three are different things.
> 
> Ridiculous; as shown above subtyping *is* the subsetting of the valid 
> values: Social_Security_Number in particular has only 10**9 values 
> rather than the Σ(n=0..Positive'Last) 256**n values that the STRING type 
> would have.

Which does not imply anything to either subtyping or substitutability. Here
are the definitions:

def. S is a subtype T if it inherits the interface of T. E.g. inherits an
operation of T. It is also called subclassing.

Example: Positive is a subtype of Integer because it inherits +.

def. S is substitutable for T in an operation f if you can pass an instance
of S where an instance of T is expected.

Example: Circle is substitutable for Ellipse in Area. Circle is not
substitutable for Ellipse in Resize. This is so-called Circle-Ellipse or
Square-Rectangle controversy.

The notion of subtypes based on substitutablity (behavioral subtyping) is
so-called LSP-subtyping.

>> Huh, great mathematical problems are about fighting constraints. E.g.
>> solving x**n + y**n = z**n in real numbers vs. in natural ones. No big
>> deal? Same applies to programming, it is mostly about working around
>> constraints.
> 
> ...that's the most idiotic thing I've *ever* heard you say.
> Constraints are fundamental for mathematical proofs; they are essential 
> for making robust programs. (HINT: definitions are often constraints.)

Hint: Diophantine equation

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