Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
> Consider Unbounded_String, Bounded_String, String. Why one cannot be a
> subtype of another? In my view it is very reasonable, because all of
> them are in fact just different representation of the same concept of
> "array of characters". And a representation has to be no issue.

You see, that's exactly what I'm talking about. You get lost
because you're thinking about "concepts" instead of the nuts
and bolts of the string types themselves. Ada is not an OO
language in its entirety, and some of those strings are just
arrays, so you're not going to get subtyping in the way you
want. If there are operations common to all types, you should
be able to capture that in generics.

> No, it is an extension of OO and ADT. It is a simple consequence of
> the principle that interface and implementation have to be separated. 

I don't see that at all. You want language support for the
notion that if an object of type A can be converted to an
object of type B, and vice versa, than a function which
operates on one should automatically operate on the other
using convert-in/convert-out. I do not see at all what this
has to do with any of OO, ADT, or separation.

> This what you require by saying:
> class Circle : public Ellipse.
> namely that Circle is convertible to Ellipse and back.

No one else thinks that this is what A : B means, though.
You would be better off if you stopped trying to overload
everyone's understanding of inheritance with a new concept
that no one associates with that.

> C++ does not allow me to define my own type relations.

Well, not for convert-in/convert-out, but plenty else.
To do what you want, you can do

struct A
{
     struct BehaveLikeB : B
     {
         A &object;
         BehaveLikeB(A &o) : object(o) { }
         // Implement B methods, affecting A object
     };
     BehaveLikeB likeB;
     A() : likeB(*this) { }
     B &asB() { return likeB; }
};

void foo(B &);
A anA;
foo(anA.asB());

> define "-": NN x NN -> NN in a most reasonable way.

Oh, sorry about that. For some reason my brain was saying
unary minus, not subtraction. Yes, for subtraction throwing
a constraint error is the way to go.

> This could be an option if the software were never modified. In the
> real world you would like to have as much compile-time checks as
> possible, even for errors which will never occur in the given version
> of the program. You never know in which direction the code will
> evolve. And there is no better mechanism for compile-time checks than
> the type system.

But the template system gives you complete type safety,
and compile-time checks! If you modify the code to use
an unavailable operation, the compiler will tell you.
All your method does is add an additional set of things
that the types must be able to do even though the code
doesn't need those operations. It is no more future-
proof than the template version, because you do not know
for sure that you will never need to add methods to the
interface.