Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Any real evidence for OOP benefits?
Message-ID: <77300043@p.cs.uiuc.edu>
Date: 7 Feb 90 02:13:00 GMT
References: <8379@<25C3AC55>
Lines: 82
Nf-ID: #R:<25C3AC55:8379:p.cs.uiuc.edu:77300043:000:3117
Nf-From: p.cs.uiuc.edu!gillies    Feb  6 20:13:00 1990


Here's the only reference about code size I know of.

Eric Harslem and Leroy E. Nelson, "A Retrospective on the Development
of Star".  Proceedings of the 6th international conference on software
engineering, 1982 September, tokyo japan.

Also available in "Office System Technology -- A look into the World
of the Xerox 8000 Series Products:  Workstations, Services, Ethernet,
and Software Development", pp 261-267.  [Available from Xerox Corp,
3333 Coyote Road, Palo Alto  CA]


Since this paper is hard to get, here are the two main quotes.

...About one fifth of Star was working by the time it was determined
that a subclassing mechanism would be needed to complete the system.
Such a mechanism was subsequently designed and implemented [Curry82].
The existing Star code was converted to use this new mechanism in
several places.

...The barchart below shows the size of the operational corpus of Star
code over the period of its development.  A plot of functionality
would have roughtly the same (y=x/2 - ed) shape.  Star actually shrank
during the conversion to the subclassing mechanism.

Quarter		Code size
1		25k
2		46k
3		55k
4		70k
5		70k
6		60k		<- shrink
7		70k
8		75k
9		80k
10		100k
11		125k
12		140k
13		150k
14		175k
15		185k
16		200k
17		240k
18		250k

These people were using a Pascal-like language, and coding conventions
to implement subclassing.  The multiple-inheritance subclassing
mechanism was called "Traits" and is documented in

Gael A. Curry, Robert M. Ayers, "Experience with Traits in the Xerox
Star Workstation", IEEE Trans. on SOft. Engineering, Vol SE-10, Sept
84, pp 519-527.

Here is the most interesting quote from that article.

"In 1982 an analysis of the OS3 Star traits graph was performed in
order to see how multiple subclassing was being used.

  In the traits graph which was examined, there were 168 separate
traits (including all of the structure discussed in Section III).
Although, as noted earlier, many of the classes used multiple
subclassing, very few used multiple subclassing in an intrinsic or
unavoidable way; minor rearrangements of the traits graph, not costly
either in program logic or in class data space, could eliminate the
multiple inherence [yielding single inheritance - don].

  The notable exception was the trait structure used to define tables
(see Figs 13 and 14).  The tables implementation used
multiple-subclassing extensively.  An examination showed that it was
intrinsic subclassing that could only be eliminated by a basic
redesign.  Interestingly, the tables facility was developed late in
the Star project, and its designer was very familiar with the traits
mechanism.

  This analysis suggested two things.  First, despite the historical
evolution of the system, which has embraced multiple-component
subclassing, it would be possible to do an after-the-fact
restructuring and "retrat" to single-component subclassing.  Second,
it was possible that the design benefits of traits were lost because
the designers, not having worked with them in the past, structured
their implementations along better-understood single-component lines."