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-Thread: a07f3367d7,c7ff90b15f15636c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!83.128.0.12.MISMATCH!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!xindi.nntp.kabelfoon.nl!news2.euro.net!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail Date: Tue, 13 Oct 2009 09:50:57 +0300 From: Niklas Holsti Organization: Tidorum Ltd User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Runtime type selection References: <2c15c8a6-b555-4d08-8fe6-f77cb207e7a6@k33g2000yqa.googlegroups.com> <4ad20fd5$0$26308$4f793bc4@news.tdc.fi> <61d081f4-cccc-4575-927f-5c400b73ff90@k19g2000yqc.googlegroups.com> <4ad23819$0$6256$4f793bc4@news.tdc.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4ad42370$0$26362$4f793bc4@news.tdc.fi> NNTP-Posting-Host: 81.17.205.61 X-Trace: 1255416688 news.tdc.fi 26362 81.17.205.61:36329 X-Complaints-To: abuse@tdcnet.fi Xref: g2news2.google.com comp.lang.ada:8690 Date: 2009-10-13T09:50:57+03:00 List-Id: Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:4ad23819$0$6256$4f793bc4@news.tdc.fi... > ... >> Did you read about the package Ada.Tags (RM 3.9)? There is a generic >> function Ada.Tags.Generic_Dispatching_Constructor that takes a tag as >> parameter and creates an object with that tag, but I don't hink there is >> any way to find the tags for all types in a given derivation class. So >> even with Ada.Tags.Generic_Dispatching_Constructor your program still has >> to register the types, or their tags, or a prototype object of each type, >> to create the program-accessible set of types/tags that can be in the >> graph. >> >> Perhaps some expert can explain why this reflection capability (find tags >> for all derived types in a class) was not included in Ada.Tags? Perhaps >> because Ada run-time systems do not need such a function for their own >> purposes? > > I think that would be impossible in general, for the same reason that the > rules about what tags are returned from calls to Internal_Tag are mostly > written with "may". The problem is that tagged types can be created and > cease to exist asychronously with respect to a call to a function in > Ada.Tags. (For instance, if another task creates a tagged type by calling a > subprogram with such a type declaration.) The model of Ada.Tags is that is > can be implemented either with a mostly static data structure (created at > link-time) or with a fully dynamic structure. In the latter case, complex > locking would be required to ensure any particular (useful) answer for one > of these functions. In the former case, something similar to the dynamic > structure (and locking) would be required to avoid returning non-existent > tags. It was felt that such requirements would add a lot of complication and > runtime cost to the implementation of this package without a corresponding > benefit. Thanks for this clear explanation, Randy. Interesting to hear that this question was actually discussed by the language definition team. > The only language requirement is that each tagged type is > connected to its immediate parent (in order to check type conversions), > anything else further would be needed only to implement your proposed > function. Well, I did not really mean to "propose" such a function, I only tried to explain to the OP (who could have made use of this functionality) that it is not provided now, but I could not myself explain why not, as you could. As I understand it, Ada is not designed to support much reflection, so the absence of this function does not surprise or disappoint me. I don't know about the OP, of course... -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .