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 02:22:53 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Extension of non-limited type needs limited component Date: Fri, 15 Nov 2002 11:22:50 +0100 Message-ID: References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1037355771 14564990 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:30929 Date: 2002-11-15T11:22:50+01:00 List-Id: On Fri, 15 Nov 2002 00:30:03 GMT, Robert A Duff wrote: >Dmitry A. Kazakov writes: > >> Which also raises an interesting question, whether T'Class should >> always inherit "non-limitness" of T. Or more generally shouldn't one >> have an ability to disallow primitive operations (like ":=" in case of >> non-limited->limited mutation)? >> >> Let we allow disallowing, then either >> >> 1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise >> an exception and so refuse to copy the limited components. > >Compile time errors are good. Exceptions (run-time errors) are evil. Absolutely >This is not SmallTalk, where you can dispatch to a method that does not >exist. 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! [ 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. 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. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de