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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7ee10ec601726fbf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-11 08:12:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!usenetserver.com!newscon06.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr11.news.prodigy.com.POSTED!not-for-mail From: "Pat Rogers" Newsgroups: comp.lang.ada References: <3BC30674.BA88AAB6@brighton.ac.uk> <9pvv3t$ves$1@news.huji.ac.il> <9q49fc$nh3$1@nh.pace.co.uk> Subject: Re: why not "standardize" the Booch Components? (was Re: is Ada dying?) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: NNTP-Posting-Host: 208.191.176.121 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr11.news.prodigy.com 1002811593 ST000 208.191.176.121 (Thu, 11 Oct 2001 10:46:33 EDT) NNTP-Posting-Date: Thu, 11 Oct 2001 10:46:33 EDT Organization: Prodigy Internet http://www.prodigy.com X-UserInfo1: OP]QRACE[BWMQ_H]]ZN@_TDAYZOZ@GXOXB_J]Q]KEYUNDQUCCNSUAACY@L[ZX__HGFD]JBJNSFXTOOGA_VWY^_HG@FW_HUTHOH]TBPGCO\P^PLP^@[GLHUK@WLECKFVL^TYG[@RMWQXIWM[SDDYWNLG_G[_BWUCHFY_Y@AS@Q[B\APPF@DCZM_PG_VSCPQZM Date: Thu, 11 Oct 2001 14:46:33 GMT Xref: archiver1.google.com comp.lang.ada:14270 Date: 2001-10-11T14:46:33+00:00 List-Id: "Marin David Condic" wrote in message news:9q49fc$nh3$1@nh.pace.co.uk... > I looked over the Booch Components several years ago and have not revisited > them since. Perhaps they have evolved some since then so my comments may not > be appropriate. Quite a lot of work has been done (by Simon) over the years. (That is an understatement!) > One big weakness I found in them was a general lack of documentation. If > *any* set of data-structury-ADT-ish stuff is to be adopted as a de-facto > standard (presumably, tacked on with compiler distributions, etc.) it would > need some documentation that explains the behavior and proper use of the > classes/packages. You can't dump a library on a newbie and say "Here: Read > the code and figure it out for yourself..." It need not be a textbook, but > some minimal level of a user's manual needs to be there. Absolutely agree. > Demo/Test programs - it had some when I looked it over. I thought they could > stand to be a little more thorough and possibly illustrative of proper > usage - build a document that hyperlinks to example & test code? Sure. > It ought to be noted that something like the Booch components are not going > to be suitable for all applications. If they rely on dynamic memory, they > may be unsuitable for any sort of realtime work. If they rely on fixed > memory, they may not be suitable for very dynamic workstation apps. If they > provide both implementations, they may be "too big" and/or offer too many > choices to the user. IOW, they cannot be all things to all users and hence > it should be clear as to what the intended usage is. Yes, that's true, but at least the storage management is an explicit part of the abstraction when allocations are involved -- one has to specify the pool to instantiate those components. For predictable storage allocation one would use, for example, a fixed-block pool. Barnes' book has one, and I show one in my Real-Time Ada course, so they aren't hard to get. Better yet would be to add it to the existing BC pool managers already available. I'll see if Simon is open to that. > One thing that may be important is to consider how they might be extended to > include new features should the need become apparent. Could this serve as > the basis for a more general library of components rather than just a > data-structure library? (Bundle into it things like an OS interface, network > support, math libraries, etc.?) I would think it should be a separate part of an overall library. For now, standardizing on a collections library would be a *big* step forward. > Also, one of the things I found very useful in the MFC was the ability to > "serialize" an object. The same thing is possible in Ada95 with streams. It > would be A Good Thing if the Booch components provided Load/Store operations > from/to a Stream file. That's the kind of thing I would hope to see added (along with documentation, for example) once the components become widely adopted and available for extension by the general community. --- Patrick Rogers Consulting and Training in: http://www.classwide.com Real-Time/OO Languages progers@classwide.com Hard Deadline Schedulability Analysis (281)648-3165 Software Fault Tolerance