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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!nuzba.szn.dk!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: Mon, 13 May 2013 21:52:15 -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> <1181wq8vjk781.2wo8wfbtbr61.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368499936 10751 69.95.181.76 (14 May 2013 02:52:16 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 14 May 2013 02:52:16 +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 Xref: news.eternal-september.org comp.lang.ada:15548 Date: 2013-05-13T21:52:15-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1181wq8vjk781.2wo8wfbtbr61.dlg@40tude.net... > On Fri, 10 May 2013 20:00:39 -0500, Randy Brukardt wrote: > >> "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. > > How to separate Employer and Employee? It makes no sense to separate them. They're instances of the same thing (I've been both simultaeously, for example). And if you did separate them, you are going to have to have components of the other kind. So what? "component of" does not suddenly break an abstraction or eliminate separation, any more than having a parameter of a type eliminates separation. ... >>> 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. > > In which sense? From the implementation point of view GNAT's File_Type is > an address or integer, if I correctly remember. It does nothing. No one ought to care about the "implementation point of view". You design specifications for the client, the implementation is whatever you need. > From the > user's point of view Put_Line, Get_Line do not even mention File_Type. And > there are lot of questions to Text_IO design anyway. One problem is worth > mentioning. It is a typical God-class design: > > http://en.wikipedia.org/wiki/God_class > > This is the destination point of the idea of equivalence of object and > abstraction, a very OO idea. What you are talking about is basically > classic OOA/D put in different terms. I don't see any reason whatsoever that keeping your types separate is going to somehow lead to a "god_class". And of course OOD uses the same ideas -- it would be silly to ignore the common sense lessons of modular programming, OOD was supposed to build on top of them. But they got all tangled up in OOP religion, worrying about "inheritance" and "object purity" and other silly things rather than getting the problems solved. (And most problems don't lend themselves very well to OOD religion.) Randy.