Re: Extension of non-limited type needs limited component

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On Fri, 15 Nov 2002 00:30:03 GMT, Robert A Duff
> <bobduff@shell01.TheWorld.com> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> Sure? And what about this:
> 
> type A is tagged ...
> procedure Foo (L, R : A);
> 
> type B is new A with ....
> 
> X : A'Class := Some_A;
> Y : A'Class := Some_B;
> 
> Foo (X, Y); -- Oops, dispatching to nowhere!

True.  But I'm not happy about it.  And it doesn't mean single-argument
dispatching should be made more dangerous to match double-arg
dispatching.  ;-)

> [ Not that I argue for SmallTalk, of course (:-)) ]

;-)

> Then disallowing is already allowed for non-tagged types =
> "is abstract". 
> 
> Further one can always override with a subroutine that throws
> Program_Error. Is that better? IMO it is the same.

Yes, it is the same.  I see no reason to add special syntax to make it
easy, though.

Note that Java more-or-less prevents this problem by making exceptions
part of the visible contract.  I think they got some of the details
wrong, but they are on the right track.  The Java rules are a pain,
but I think they could be modified to make them work nicely.

>... The only real
> difference is that one cannot get rid of overloading of the undesired
> operation. What is actually required. I think that there could be
> situations where it would be useful to disallow an operation in the
> public interface and to override it with something working in the
> private one.

Hmm.  What example?  It seems to me that hiding/disallowing the
operation for the derived type is dishonest, because a client can always
call that operation by converting to the parent type 'Class and
dispatching.

Note that you can say:

    type T is new A with private;
    ...
    type T is new B with record...

where B is derived from A, and has more operations.
This is a useful capability, and is similar to what you asked for above.
The "more operations" are visible only inside T package.
Clients can't convert to B, because they can't see that T is "really"
derived from B.

Here's an idea I've been thinking about for some years, which might
address your desire to "take away" operations:
Define two kinds of inheritance, "is a" inheritance, and "is like a"
inheritance.  When you use "is a" inheritance, you can only *add*
operations, and you can convert to the parent type.  When you use "is
like a" inheritance, you can also take away operations, but you are
forbidden from converting to the parent type.  With "is like a"
inheritance, you are defining a new abstraction that is similar to
the parent, but you don't claim that it "is a" parent, and you don't
want to view the new type *as* a parent.  What do you think?

- Bob