Re: c++ vs ada results

[munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!chook!andrewd@uunet.uu.net (Andrew Dunstan)]

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  #                                 #
#######################################################################