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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1e3f2eac5c026e3 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-28 18:09:02 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 28 Dec 2003 20:09:00 -0600 Date: Sun, 28 Dec 2003 21:08:59 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Other Ada Standards (was Re: SIGada Conference) References: <468D78E4EE5C6A4093A4C00F29DF513D04B82B08@VS2.hdi.tvcabo> <3FE991DD.5060301@noplace.com> <3FEA5C82.8050309@noplace.com> <3FEB047A.1040100@noplace.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-fhM3asIG9nsrkfH2bAMmBkbYhqb2Sf77tE8ZREmqIUqq6pmFuOM4VbOqUEza2RFNCX3gxCFsuHk+32o!SanoUxil/Ktglp9GQ+SKyQgBVZWMVXruyIdb1gLnT27bPBQiwG6iZUotTKEP6Q== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:3907 Date: 2003-12-28T21:08:59-05:00 List-Id: Dmitry A. Kazakov wrote: > Right. But if they are related? Deeply nested generic child units? Does not > the language encorage designers to use larger compilation units because > otherwise users will be "punished" by larger with/use blocks? This was an occasional problem in Ada 83, in Ada 95 I think the only major case left to fix is mutually interdependent types. And it will be fixed. But as a writer you have to ask yourself, every time you go to with something that wasn't in your original design, whether the design was wrong, or your implementation is wrong. I guess I find three about equal sized groups of cases: The original design WAS wrong, the implementation chosen is not wrong, but does need more visibility (almost always in the body) than was anticipated by the design, and the third case, this implementation is wrong, fix it. If you take that attitude, the number of with clauses is just not a burden. > I think that we have reached the level of complexity where it becomes a > heavy burden for a reader to analyze all with's and use's. Tools might > help, but there is still a problem. No real argument with that statement, just a warning. When a project does get to that point, you had better be almost finished, or go back now and do a redesign. At MITRE we found that this was one of the nicest things about Ada. When the contractor started complaining about slow compiles or needing better tools, it was time to examine the source and compare it to the design documents. Almost always there was a particular design problem that needed to be fixed. Sometimes it was "just" a programming problem, but often it reflected too ambitious (and unrealistic) requirements or serious hardware problems. One of my favorite examples involved a lot of kludgeware to merge two message streams. Why merge the message streams? Well the requirements specified a throughput of more messages per minute than one 9600 baud connection could handle. But the actual requirement anticipated that many messages over a single channel. We allowed the contractor to test with a 19200 connection, and went back to the government customer to figure out if the requirement was real, and we should upgrade the communications hardware. (It turned out to be cheaper to upgrade the modems than redo the requirements analysis. ;-) > True, this the same problem, but it is one level beneath. You are talking > about type interfaces, with/use issue is sort of "package interfaces". With > type interfaces and abstract types we can hide uninteresting details. > Probably it is time to go this way for packages. No, it is the same issue. Interface inheritance will allow a package to import several ADTs and combine them in one new type. But the package that contains the interface instantiation will EXPORT all of the operations that are collected by the interface. So users of the type created by the interface instance will only need to with (and possibly use) one package, not several. You can do, and I do, the same thing today with a succession of type derivations, each using a generic mix-in. Interfaces will make this easier. The private part of a package containing a series of mix-ins can get pretty long, and you often need to do some renames in the package body. If you want to call this multiple inheritance, fine. But I think of it as constructing a type from component ADTs. Whether there is an isa relationship to several types, or just a record type with several component ADTs, the program structure is the same: The unit that creates the ADT has withs for the compontents, users of the created ADT need only with one unit. If the average number of withs per package is say two per spec and three or four per body, you are doing good. Four per spec and ten per body is acceptable in a final product. But when it looks like you are getting beyond that watch out. Doing the necessary refactoring will take time, but it will reduce the number of bugs to be found once coding is complete drastically. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush