From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05,MSGID_SHORT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 1 Jul 91 05:15:16 GMT From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!chook!andrewd@uunet.uu.net (Andrew Dunstan) Subject: Re: c++ vs ada results Message-ID: <3906@sirius.ucs.adelaide.edu.au> List-Id: In article <1991Jun26.224737.16660@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: |> >I have read this and used a few of the tools. It has a useful set of |> >tools, but there is just something about it that occasionally annoys me. |> >Maybe it's just that I don't like identifiers like |> >the_small_brown_dog_with_a_broken_left_front_leg! :-) |> |> These names arose because Booch needed/wanted a way to unambiguously |> specify the chief attributes of each abstraction (because of the semi- |> combinatorial nature of the ways in which these attributes can be |> mingled, there are cases where you have over a hundred flavors of a |> particular fundamental kind of component, such as a queue). This is, |> he'd be the first to admit, one of the places where inheritance would |> be a natural match, since one could use it to specialize--his C++ |> version of these same components exploits inheritance. |> I did have a smiley, Jim! Long package names I grant you, but I do find names like of_the_set a bit annoying. Just a matter of taste, I guess. While we are on this subject, Booch says that he rarely uses USE clauses, because they "pollute the name space". I routinely use USE, and find that it makes the code more readable. Using qualified names all the time is a pain in the neck. Neither of these considerations would make me refrain from using Booch's components. |> >Seriously, what I find disconcerting is that his abstractions have a |> >strange feel to them. They don't reflect the way I think about objects, |> >so using them is a bit too much of an effort. (This is an important |> >issue in program/library design!) |> |> I would be interested in an elaboration of this point, since I am hard |> pressed to imagine what you find disconcerting or strange about the |> components--they're just things like lists and queues and rings and |> stacks. Pretty mundane, really. Ok, what follows is subject to the following caveat: I think Booch's book and components are valuable resources. There is a lot we can learn from them about good ways of doing things. It was a while since I looked at the book, and then I did not do any analysis of it, but gathered impressions. So when I saw your posting I went and got a copy of the book and looked at it over the weekend. Here are some thoughts. The stuff on conceptually linear structures (lists, stacks, queues, rings, strings) I generally have no quarrel with. Maps, Sets and Trees, however, are more problematical. I generally think of sets in functional terms. Hence, my sets package has union, intersection, set-difference etc. as functions returning sets. Similarly for maps, (which are really binary relations). When I was working last year on binary relations, I looked at Booch's maps packages and decisded that they did not do what I needed. Here is a piece of code from a program that used the package that I eventually wrote (It works out the Director Symbol sets for the productions in a grammar): DirSet := -- the follow set of the left hand side if there is no right hand side, Rules*Null_Rule*pred*G*FOLLOW -- or the first set of the leftmost symbol, or Rules*succ*LeftMost*G*FIRST -- or the follow set of the lhs if the right hand side is only one nullable -- symbol or Rules*succ*LeftMost*Nullable*RightMost*pred**2*G*FOLLOW -- or the first set of the symbol following the leftmost symbol if the -- leftmost is nullable, etc or Rules*succ*LeftMost*(+(Nullable*Next))*G*FIRST -- or the follow set of the lhs if the right hand side is completely nullable or Rules*succ*LeftMost*(+(Nullable*Next))*Nullable*RightMost*(+Prev)* Leftmost*pred**2*G*FOLLOW; All the objects here are binary relations. "*" means relation composition and unary "+" means relation closure. Booch's maps tools do not provide these operations. Worse (from my point of view), if he did provide them it would be via procedure calls rather than function calls. This involves a serious limit on the expressiveness given by his components. I know (at least I think I know) why he has done it this way. It is safer to do it like this, and so the managed forms will have the same interface as the unamanaged forms. (I was dealing with the equivalent of his sequential_unbounded_unamanaged forms). But the safety and uniformity come at a high price. The loss of expressive power is not small. What happens here? You can quickly accumulate MASSIVE amounts of garbage. Ok, then, let's get better (existant?) garbage collectors instead of doing things in a less than intuitive way. There is also a problem in the level of abstraction applied. I use trees quite a bit, but usually as a representation of something else (a set for example). In fact Booch's first example of a tree in his chapter on trees is of something that is not conceptually a tree at all: it is a bag (strictly an ordered bag). Now there is nothing wrong in using an ADT at one level as the representation of an ADT at another level, but it is a pity that Booch did not give an example of a tree as an ADT instead of using it to represent something else. Lastly, the SWAP operation in some of these components (e.g. trees) is a bit odd. Yes, I have read your defence of them in later mail, but this seems to me to miss the point a bit. An ADT interface should be independent of safety and management considerations, as far as possible. I hope this is enough elaboration for you! p.s. like you, I am an Ada fan. ####################################################################### # Andrew Dunstan # There's nothing good or bad # # Department of Computer Science # but thinking makes it so. # # University of Adelaide # # # South Australia # - Shakespeare # # net: andrewd@cs.adelaide.edu.au # # #######################################################################