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: a07f3367d7,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.11.239 with SMTP id t15mr1645376wib.3.1368583408471; Tue, 14 May 2013 19:03:28 -0700 (PDT) Path: p18ni110077wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.139.MISMATCH!xlned.com!feeder7.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nrc-news.nrc.ca!News.Dal.Ca!news.litech.org!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Thu, 9 May 2013 10:04:40 +0200 Organization: cbb software GmbH Message-ID: <1nw4bxyvk1gj5.xmiirr0diavq$.dlg@40tude.net> References: <1luaso698dpcc$.rrv8385qwl92.dlg@40tude.net> <1xlzfj8qy1zey$.up1s1v3syagv.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 15waz9CoS+eMakbyhTPyFQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-05-09T10:04:40+02:00 List-Id: On Wed, 8 May 2013 15:37:24 -0500, Randy Brukardt wrote: > "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. There are good arguments for having all parameters either controlled or else class-wide. > 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. The language should prevent operations from being non-primitive, except for maybe in the package bodies or nested. >>> 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. There is no "little" and no "big" types. It is simply wrong to think about software design in such terms. It was a very bad OO idea to separate types into "classes" and other types. An abstraction is always too large for a single type. It cannot be otherwise. > 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. There should be no helper types in a properly designed language. Each type should express/implement something useful from the problem space. Index is such a thing. There is nothing in it that would make it less important than the array type, or the array element type. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de