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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f93e461e8491e322 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news2.google.com!news.maxwell.syr.edu!newspeer.monmouth.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Limited_Controlled, orthogonality and related issues Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1169139744.717060.69070@51g2000cwl.googlegroups.com> <1169140582.275634.126300@51g2000cwl.googlegroups.com> Date: Fri, 19 Jan 2007 10:05:35 +0100 Message-ID: NNTP-Posting-Date: 19 Jan 2007 10:05:35 CET NNTP-Posting-Host: 4394ac17.newsspool3.arcor-online.net X-Trace: DXC=9DC>C7;K00bFXUDVUnEXQmMcF=Q^Z^V3h4Fo<]lROoRagUcjd<3m<;b=j?>N]oPSbd[6LHn;2LCVn7enW;^6ZC`dIXm65S@:3>o4Qj`_nai6Sf X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8315 Date: 2007-01-19T10:05:35+01:00 List-Id: On 18 Jan 2007 09:16:22 -0800, Adam Beneschan wrote: > Adam Beneschan ranted uselessly: > >> On looking at this, I wonder if this was an error in the design of Ada >> 95. Primitive operations of tagged types are dispatching, and the >> reason is that so that another package can declare a type extension >> from a tagged type and inherit the dispatching operation, and possibly >> override it, and then somebody could use the operation on a class-wide >> type to call the correct operation for that particular object, and thus >> achieve polymorphism. But when the partial view of a type is not >> tagged, then other packages can't derive type extensions from it and >> can't apply 'Class to it, so was there any logical reason why an >> operation on that type (declared in the visible part of the package) >> should be dispatching? Maybe not, since the dispatch could "almost >> never" take place in practice, and since making the operation >> dispatching adds restrictions just like the one Maciej found. >> >> I say "almost never" because in theory, since the private part or body >> of P or of a child of P (or the visible part of a private child of P) >> *could* derive a type extension from the tagged type and dispatch. But >> I'd guess that such usage would be rare. >> >> So it seems to me that (1) it would have been better to say in 3.9.2 >> that a primitive operation of an untagged private type whose full view >> is tagged is not dispatching, at least if the operation is declared in >> the visible part of the package; or (2) some way should have been >> provided for the programmer to specify that an operation that 3.9.2 >> defines as "dispatching" really isn't. >> >> Maybe (2) is still possible. I'm guessing that it's way too late to >> make (1) the rule. So this is probably really just a useless rant. > > On reflection, maybe there *is* a way to fix this: Change the first > sentence of 3.9.2(1) to read, "The primitive subprograms of a tagged > type are called dispatching operations, except that a primitive > subprogram of two or more tagged types is not a dispatching operation > if it is declared in the visible part of a package, and every type of > which the subprogram is a primitive operation is an untagged type or a > tagged type whose partial view is untagged". Or something along those > lines. The idea is that a change like this would have no effect on > programs that are currently legal, so it seems like it should be safe. > And it would make programs like Maciej's original attempt legal, as > they (IMHO) should be. I think that this idea is wrong because it fixes broken public view [non-tagged but dispatching], by breaking the private view [non-dispatching but tagged]. I think that the guiding rule should be that all views of the same thing shall be consistent. For this reason it would be better that for such subprograms the private view of such subprograms were class-wide: package type T is limited private; procedure Foo (X : in out T); private type T is new Ada.Finalization.Limited_Controlled with ...; -- -- Here Foo is seen as -- -- procedure Foo (X : in out T'Class); -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de