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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: container cursor type cannot be tagged References: <85ppfkxvwg.fsf@stephe-leake.org> Date: Fri, 29 Aug 2014 09:50:40 -0500 Message-ID: <85d2bjxscf.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) Cancel-Lock: sha1:ZldcC7/cnHPKve4S08HX5N++3BQ= MIME-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 4442c54009349e3fb833018522 X-Received-Bytes: 2447 X-Received-Body-CRC: 343449057 Xref: news.eternal-september.org comp.lang.ada:21984 Date: 2014-08-29T09:50:40-05:00 List-Id: "Randy Brukardt" writes: >> One solution to this is to define a new aspect Controlling_Type: >> >> overriding function First (Object : Iterator) return Cursor >> with Controlling_Type => Iterator; >> >> which says to not use Cursor to dispatch calls to this subprogram. That >> would be useful in other similar situations. I didn't find an AI on this >> issue; would this be worth a proposal? > > Well, that's up to you. I'd think it's pretty weird; if one really wants a > non-dispatching parameter, it should be declared as class-wide. Ok; at least you didn't say "we looked at that and it won't work because ...". >> Another solution would be to provide another version of >> Ada.Iterator_Interfaces, where Cursor is explicitly tagged, and these >> functions use Cursor'Class. That seems more of a kludge. > > That seems to make more sense, honestly. But how are you dealing with the > "can't have two tagged types" problem for the container itself? I don't see the problem; I declared my container with tagged container and cursor, and only had a problem when I tried to instantiate Ada.Iterator_Interfaces. On the other hand, I hope that the Controlling_Type aspect could be used to resolve any problems due to multiple tagged types. I agree that deriving from the container and cursor together is not a solved problem. This arises from the confusion of "derivable" and "can use object.method" features; both depend on the type being tagged. In my case, I don't care about further derivation, but I do care about object.method. So my solution is just to say "this container design is not intended to support derived containers". Perhaps we need to borrow "final" from C++11/Java? -- -- Stephe