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,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.68.197.196 with SMTP id iw4mr5137373pbc.7.1368583268046; Tue, 14 May 2013 19:01:08 -0700 (PDT) MIME-Version: 1.0 Path: bp1ni2329pbd.1!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nrc-news.nrc.ca!newsflash.concordia.ca!News.Dal.Ca!news.litech.org!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Wed, 8 May 2013 15:37:24 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1luaso698dpcc$.rrv8385qwl92.dlg@40tude.net> <1xlzfj8qy1zey$.up1s1v3syagv.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368045445 15392 69.95.181.76 (8 May 2013 20:37:25 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 8 May 2013 20:37:25 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Received-Bytes: 4027 Date: 2013-05-08T15:37:24-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1xlzfj8qy1zey$.up1s1v3syagv.dlg@40tude.net... > On Tue, 7 May 2013 15:27:58 -0500, Randy Brukardt wrote: ... >>> Another problem is that you cannot make everything Controlled without >>> MD. >>> Because otherwise you will permanently run into problems with primitive >>> operations of multiple types, multi-methods etc. >> >> Say what? Making everything controlled simply means that every type has a >> Finalize operation. Dispatching *within* a Finalize operation is usually >> a >> disaster (you don't want to redispatch as you might be finalizing the >> parent >> part of some child type), so what that has to do with MD is beyond my >> comprehension. > > That is a different issue. I meant that if A and B are controlled/tagged > you will have troubles in using them as parameters of same subprogram. > Even > two parameters of same type is a problem already. Only MD can resolve > that. That's only a problem if the routine is primitive for *both* types. And that's only a problem if the types are declared in the same package, which is already a bad idea because it means that they have excessive coupling. I'm sure it happens once in a while, but it shouldn't be happening often. ... >> I suppose you might get into trouble if you mistakenly try to declare >> multiple tagged types in a package, but that's always a bad idea and >> should >> be avoidable in almost all cases (possibly with careful use of limited >> with). > > I don't see why is it a bad idea to have related types declared in one > package. On the contrary it is a good idea to group related things in a > way > making it easer to use. I am glad that Ada does not tie types to packages. One O-O type per package is the only model that makes sense. It's fine to include "helper" types in the package (stuff like enumerations, integers, and the like), but you should never mix the "big" abstractions of your program. I was never talking about "little" types, like the ones used to interface to hardware -- these should be hidden in bodies anyway. If you can't separate the "big" abstractions, you have too much coupling. Your example of the array index is certainly not the sort of case that I'm talking about; that's a "helper" type and I certainly agree that it's best declared with the array. But this is the sort of type that's logically part of the larger abstraction and is declared separately just because Ada requires that; it really should be declared as part of the same declaration. Randy.