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,fba93c19bb4e7dbd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-22 00:37:53 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news.rediris.es!news-ge.switch.ch!switch.ch!solnet.ch!solnet.ch!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Q: Endless loop by dispatching Date: Tue, 22 Jul 2003 09:41:57 +0200 Message-ID: <25pphvct4bsdc5ag0rrnftoitlqgombm25@4ax.com> References: <3F188FDA.3000202@attbi.com> <3F18DB9D.5020205@attbi.com> <818nhv0hrmlheu622t82574blao7bqr0tt@4ax.com> <3F1BBB9B.2070800@attbi.com> <3F1C360E.8010208@attbi.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: news.uni-berlin.de 1058859469 16074030 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40611 Date: 2003-07-22T09:41:57+02:00 List-Id: On Mon, 21 Jul 2003 18:51:34 GMT, "Robert I. Eachus" wrote: >Dmitry A. Kazakov wrote: > >> Another evil is that constructors/destructors are exposed as "normal" >> operations having some special semantincs attached to them *depending* >> on the context. This also won't work. The word "Initialize" suddenly >> becomes some very special for the compiler in the private part, being >> just a name in the public one. If it were just a procedure Foo, one >> could probably live with it. > >Initialize (and for that matter Ada.Finalization) is just a convenient >scapegoat to use in examples. The problems can occur with any >predefined operations of a tagged type. Yes, but for Initialize/Finalize the consequences are usually catastrophic. This is why I would prefer either a special syntax (C++ way), or a more general approach with overriding by extension. Which can be later well re-used: 1. for user-defined aggregates, if they come; 2. for overriding entry points of tagged tasks, if ...; 3. for overriding operations of tagged protected objects, if ...; >(But there is this one package >in the RM that declares tagged types which is why it tends to get used >in examples.) > >> IMO it should be illegal with any pragma: >> >> package A is >> type Public is tagged private; >> procedure Initialize(X: in out Public); >> private >> type Public is new Ada.Finalization.Controlled with... >> -- Error public and private views are incompatible! >> end A; >> >> It could be made legal only if primitive operation disallowing were >> supported: > >That is an interesting approach. I can't see justifying disallowing it >entirely, but saying that: > > not overriding procedure Initialize(X: in out Public); > -- or whatever syntax is chosen > >becomes illegal in the private part might be a good idea. At least it >prevents the misleading use of the keywords. If we still have "may >override" and add my "will override" then the programmer gets to choose >what to say publicly, which is nice, and still get the advantage of the >compiler checking his assertions. > >> A more interesting case: >> >> package AA is >> type Public is tagged private; >> private >> type Public is new Ada.Finalization.Controlled with... >> end AA; >> >> with AA; use AA; >> package B is >> type Public_Public is new Public with private; >> procedure Initialize(X: in out Public_Public); >> -- This is legal. B knows nothing about Public's origin >> -- so it cannot misuse it >> private >> type Public_Public is new Public with ... >> end B >> >> package AA.C is >> type Private_Public is new Public with private; >> procedure Initialize(X: in out Public_Public); >> -- This is an error. C knows Public's private, so >> -- its private part is illegal >> private >> type Private_Public is new Public with ... >> end AA.C > >Change Private_Public to new Public_Public with private and you will >begin to understand the problem. AA.C.Initialize would override >B.Initialize everywhere, but would only override AA.Initalize, assuming >that there is one, in some areas of its scope. If you mean this: with B; use B; package AA.D is type Private_Public_Public is new Public_Public with ...; end AA.D; then it should be again a compile error, because AA.C "knows" that Public_Public has a private Initialize which collides with the public one. The rule is simple - there should be no way to create a context where both versions of Initialize could be visible. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de