Inheritance and encapsulation

[R James Noble <kjx@comp.vuw.ac.nz>]

Some thoughts on the interaction between inheritance and encapsulator.

Currently, inheriting from another object does two things -

1) the child gains access to priavte methods of the parent,
	(the child's private interface is extended by the 
	private interface of the parent).
2) the child's public interface is extended by the public interface
	of the parent.

I am wondering if there is anything to be gained from seperating these two.

I note that in any case the child gains access to the public
(external) interface of the object - as if using simple messages to
access the object.

Allowing point 1) without 2) seems to provide much the same as C++'s
friends in self - a object can access the implementation of another. In
this case it may make no sense for the child's public interface to be
exteneded with that of the parent. This happened to me in the
definition of a stream class for lists: the stream needed access to
the individual links of a list which needed part of the lists private
protocol: however the list stream object did not want any interface
inherited from the list object. In any event, functionality could be
manifestly exported by child methods doing resends. This would also
simplify the encapsulator objects I need :-)

Allowing point 2) without 1) would allow an object to specialise
another object without knowlege of the parent object's private
protocol. This may have some use when using strict data parents when
there is no reason why the child should have access to any internal
interface. It should have different behaviour considering multiple
inheritance and resends - but doesn't seem to be as useful as private
access without public interface extension.

james

R James Noble, Graduate Student, Computer Science Department
Victoria University, Box 600, Wellington 1, New Zealand
kjx@comp.vuw.ac.nz