🚀 go-pugleaf

In article <jubo.720960526@rwthi3>, jubo@rwthi3.informatik.rwth-aachen.de >
Right, if you assume inheritance=subtyping!
> In "designing" this way you will loose control over your "architecture",
> since most of the dependencies you introduce are not explicitely visible in
> your interfaces. Ok, there are a lot of tools that help (e.g. browsers), but
> to find the places of interest (i.e. which methods are executed) is a mess.

Well, as a former HW designer, and current OO programmer I have to make
the statement that HW engineers don't subclass ICs, they define glue 
electronics for combining the ICs for more functionality. If we find
something resembling inheritance it would be programmatic IC circuits,
but in this state we are really dealing with changing the internal
states of the components concerning functionality, and the effect
is very much limited to the black box (IC) itself.

I do think that one of the main issues is that we need to look at
objects and classes from a more purist and simplified view, instead
of building complex inheritance trees and speak about reuse of code
using inheritance. Maybe we should limit out efforts into writing 
reusable class components, and compromise concerning defining 
huge inheritance tree systems. And let the functionality (complexity)
appear from interaction between simple but powerful entities. Mixin
classes, for instance.

In other words, I applaude the current thinking of looking at
smaller, self-contained modules as the possible mean of designing
systems.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.