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.180.109.166 with SMTP id ht6mr1643620wib.0.1368583533069; Tue, 14 May 2013 19:05:33 -0700 (PDT) MIME-Version: 1.0 Path: p18ni110080wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!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!citadel.nobulus.com!goblin3!goblin.stu.neva.ru!matrix.darkstorm.co.uk!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: Thu, 9 May 2013 16:33:55 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1luaso698dpcc$.rrv8385qwl92.dlg@40tude.net> <1xlzfj8qy1zey$.up1s1v3syagv.dlg@40tude.net> <1nw4bxyvk1gj5.xmiirr0diavq$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368135238 28509 69.95.181.76 (9 May 2013 21:33:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 9 May 2013 21:33:58 +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 Date: 2013-05-09T16:33:55-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1nw4bxyvk1gj5.xmiirr0diavq$.dlg@40tude.net... > On Wed, 8 May 2013 15:37:24 -0500, Randy Brukardt wrote: ... >> 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. As usual, I pretty much totally disagree with your thinking here. The last statement is trivially true, of course, but so what? A program has to be built on top of a handful of "big" abstractions. And for each of those "big" abstractions, there has to be a single type which takes the lead (probably with a family of other types in support). Interactions between the abstraction has to be minimized, and preferably takes place through the lead type. In bigger systems, each of those abstractions corresponds to a subsystem (in Ada, that's best modeled as a family of child packages). Inside each of those subsystems, you'll have another family of types. But the majority of these types should not extend beyond the subsystem. You seem to claim that all types are equally important, which is obvious nonsense. And all I said is that you design your system around the handful of most important types, and those types should each get a package to themselves. (Or even a family of packages.) Mixing the declarations of subsystems is simply madness. >> 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. I hope I never, ever have to use any of your software. Claiming that the lookup result enumeration ("Found", "Missing", "Ambiguous") is as important as the symbol table data structure is insane. That sort of thinking leads to all kinds of structuring crazyness. Randy.