🚀 go-pugleaf

> There are two problems here.  The last paragraph suggests that the author of a
> component decides what may inherit from it, and how.  In other words the scope
> of re-use is being fixed in the design of the component.  

My point was that even though the component author would like to produce a
highly reusable  software component - the design/coding of this component as
a class is implicitly fixing the scope of reuse. Just like libraries of
procedures, there is a fixed part and a variable part.  One could summarize
recent progress as follows:

Component Representation		Change mechanism

Procedure				Parameter list

ADA ADTs				parameter list + generics

Classes					parameter list [+ generics]
					+ inheritance

> Although some
> object-oriented languages encourage this viewpoint (C++ being one of the worst
> offenders, IMHO), for re-use to be valuable in the long-term classes need to be
> re-usable in ways which the original author never envisaged.
> 
> inheritance which says "A is like B except ...", meaning the sub-class is NOT
> going to conform to some aspects of its parent. 

Even in cases where you can specify "A is like B except..", you have 
advanced to:  parameter list [+ generics] + more flexible inheritance

and you have deprived yourself of some of the encapsulation advantages
i.e. you would usually have to know quite a bit about the innards of a class
before "removing" some of it's behaviour 


In conclusion I suggest that as a representation of reusable components,
Classes are *probably* better than procedures, but they will not
provide quantum leaps in reuse rates for the same reasons that procedures
didn't (outside of confined domains e.g. IMSL).

This is difficult to *prove*, as studies have not yet been published of
experiences with some of the better OOP class libraries (e.g. EIFFEL).
Anybody got any *hard* info on this?