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, T_FILL_THIS_FORM_SHORT 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.66.191.130 with SMTP id gy2mr4960891pac.19.1368583738625; Tue, 14 May 2013 19:08:58 -0700 (PDT) MIME-Version: 1.0 Path: bp1ni2274pbd.1!nntp.google.com!npeer03.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!News.Dal.Ca!citadel.nobulus.com!goblin3!goblin.stu.neva.ru!gegeweb.org!news.ecp.fr!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: Fri, 10 May 2013 20:00:39 -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> <1q07vm77kfwla$.1cz0xwxspxhay.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368234040 559 69.95.181.76 (11 May 2013 01:00:40 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 11 May 2013 01:00:40 +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: 4850 Date: 2013-05-10T20:00:39-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1q07vm77kfwla$.1cz0xwxspxhay.dlg@40tude.net... > On Thu, 9 May 2013 16:33:55 -0500, Randy Brukardt wrote: > >> 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). > > Takes the lead, how? An abstraction including Employer, Employee, Factory, > Salary, Time, Duration, Integer, Address, Gender, Age ... Who takes the > "lead"? The container that wraps those things up, of course. And if there is no container, then they're clearly all separate abstractions that have to be treated that way. >> 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. > > How these subsystems are going to interact to each other? As little as possible. That's necessary to reduce coupling. Beyond that, almost exclusively by containment, that is that one abstraction contains components of another. >> You seem to claim that all types are equally important, which is obvious >> nonsense. > > Yes, I say that unimportant types need not to be exposed in public > interfaces. > > Everything declared in the *same* scope is equally important, or else you > have a design issue. What utter nonsense. Ada.Text_IO defines Count, File_Type, File_Mode, Field, and Number_Base types. If you think these are all equally important for the primary task of doing I/O, you have a real problem with perspective. File_Type does all of the work, while the rest just raise the abstraction level a bit. >> Claiming that the >> lookup result enumeration ("Found", "Missing", "Ambiguous") is as >> important >> as the symbol table data structure is insane. > > How do you measure importance? You don't have to quantify it in order for it to be a useful idea. If it's not obvious, your design is already too unstructured. > It is not a simple question. If you tried to roll up a measure and apply > it > most commonly used types, you would probably see your the idea of leading > types (which, BTW, is one of most damaging ideas in OO ever) quickly > falling apart. I don't see any reason to quantify "importance". Almost every package that I've designed (as opposed to tossed stuff in, and there are a number of those. ;-) has a single type around which everything else is built. There are a few (like the containers) that have a pair of such types -- but that always proves to be a problem in practice. I don't quite see what this has to do with OOP; I've used this design pattern since I first encountered a package (in the form of a Modula module) in 1978. That predates OOP doctrine by a number of years (some of the principles already existed, especially in Simula, at that point). Randy.