From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab66185f2bca0483 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-15 13:57:11 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uunet!sea.uu.net!sac.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Extension of non-limited type needs limited component User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Fri, 15 Nov 2002 21:56:30 GMT Content-Type: text/plain; charset=us-ascii References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:30966 Date: 2002-11-15T21:56:30+00:00 List-Id: Dmitry A. Kazakov writes: > On Fri, 15 Nov 2002 00:30:03 GMT, Robert A Duff > wrote: > > >Dmitry A. Kazakov 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