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: 103376,c1fe4bc1dd51fc87 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.germany.com!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: User-defined type attributes Date: Mon, 17 Mar 2008 16:03:10 -0500 Organization: Jacob's private Usenet server Message-ID: References: <928f737d-955f-415b-93b1-ddbd24fbf81e@e25g2000prg.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1205787821 25376 69.95.181.76 (17 Mar 2008 21:03:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 17 Mar 2008 21:03:41 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:20453 Date: 2008-03-17T16:03:10-05:00 List-Id: "Eric Hughes" wrote in message news:c6b7e0b5-6b81-486a-8054-becd0df9842b@h11g2000prf.googlegroups.com... ... > Tagged types do work better, sure. But they're not a panacea, > either. It would a mistake to address other difficulties with types > by shoehorning "solutions" to them into tags. And in the last couple > of days I've realized the problems with untagged types as formal > parameters is much greater than the absence of dot-notation. > > So here's a brief example. I'm writing a smart accessor package set > right now. As something of an exercise, I'm doing this as generically > as possible. So I'm looking to write code that can use both intrusive > (part of the managed object) and accretive (separate from the managed > object) allocation strategies for reference counts. And I want to do > it without making the accessor types tagged. Since an intrusive > accessor is simple a wrapped-up access object, adding a tag would > double the machine size of an object. I consider this a poor result > for a system-level library. > > My first foray at solving this was to use a formal type parameter for > the implementation of the accessor. The intrusive implementation > would contain just an access object; the accretive one would have that > plus an access to a reference count. Pretty simple, so I thought. > But without using a tagged type in the formal parameter definition, > there's no visibility either for record components or for implicit > visibility of operators on that type. Thus I couldn't get at > components either directly or indirectly. I discarded that approach. > > It's a shame really, because it would otherwise be a natural > representation of variety of in possible implementations. I'm still > looking at other ways of approaching the problem. I'm beginning to > suspect that doing this may be impossible, but I don't have an > argument yet. In cases like these, you have to pass accessor routines explicitly. Something like: generic type T is private; procedure Increment_Count (Obj : in out T) is <>; function Count (Obj : in T) is <>: ... package Whatever is ... Note the use of <> in these formal subprogram declarations. It gives a default for the subprograms such that a routine with the right name and profile automatically matches. (Why you can't have such defaults for types is unknown by me...) This makes the instantiations less annoying (but you do need to declare the appropriate routines somewhere). You can wrap these things up and use them as formal packages if they are common, so you don't necessarily have to end up with lots of generics with a hundred parameters. I would prefer to use an interface or tagged type here, but obviously you can't do that. This is not a perfect solution, but it works and is commonly used. Randy.