[MUD-Dev] (no subject)

[John Buehler]

>From: KevinL <darius at bofh.net.au>
>Date: Mon, 20 Nov 2000 13:07:01 +1100

My apologies for starting a new thread with no topic.  I recently made the
mistake of installing a piece of software that moved my email into Hotmail -
direct replies result in Hotmail appending its little advertising blurb and
the list doesn't accept such postings.  So I have to manually construct the
replies.  I forgot the subject...

>You're right in the case of doors in rooms, where more than one door in a
room
>is a reasonable occurence.  However, if you look at the situations where
>you've got only one instance of the behaviour occurring (for instance,
adding
>"lockable" to a chest), you'll find very little difference between those
two
>relationships.

Until you realize that you need to toss in another door.  Maintenance of
these systems is where things start to fall down.  We've been able to get
away with multiple inheritance as a means of tackling lots of problems
because most of the constructions that we've attempted have either worked
out or we've finagled them to work.  The classic "If you have a hammer,
everything looks like a nail" scenario.  The component camp has begun to
gain momentum because of the maturing of our understanding.  I was a babe in
the woods until I ran into Tony and Clemens (and various people who worked
with them, including Crispin Goswell and Craig Wittenberg to name two more).
It is my fervent hope that I don't misrepresent any of this as two years
really isn't enough to know it all.  The research team I was on is still
working through how you actually build applications using components.  It is
absolutely FASCINATING stuff.

>In fact, by componentising, you don't really solve the "collision" problem
>anyway.  The case I got into the discussion on in particular was
materials -
>the difference between inheriting the attributes for "steel", and adding a
>component called "steel".  In the second case, you can easily add "cloth"
as
>well (say, chain mail or something similar) - but the collision between the
>attributes of the two components still has to be managed in some way, the
same
>as it would if you were inheriting.

The idea of bringing together behaviors must be done very carefully.
Software contracts make statements about the state of a component and what
behaviors it can perpetrate upon that state.  If we want to say that an
object is both steel and cloth, that's fine.  But the component must
explicitly establish the relationship between the contracts that establish
that the component is both steel and cloth.  Depending upon the contracts
involved, it may not be possible (e.g. the contract that answers the
question "What is your single material?" makes no provision for multiple
material types).  Strictly establishing those contracts enables the designer
to discover if he's trying to construct something that is either ill-advised
or impossible.  Defining and manipulating software contracts was a focal
point of the research.

>The only difference I can really see is that, in inheriting, it's assumed
>you're picking between one or the other, and the behaviour is encapsulated
in
>the object - whereas in componentising, you externalise the behaviour, and
>build yourself a way to handle both sets at the same time.  In that
respect,
>it makes sense to use components rather than inheritance.  But then each
>object does not carry it's own behaviour itself necessarily - and in some
>environments that makes a difference (think, particularly, distributed
objects
>where the objects can migrate from server to server - the object itself
needs
>to know how to resolve conflicts anyway, so it's implementation might as
well
>be inherited as componentised).

Sorry, you lost me.  As you say later, terminology in this area is a bear.

>I'd also say writing off inheritance of implementation as "never needed" is
a
>bit rash.  Can you explain what you mean by that a bit more?  At the
moment,
>I'm using multiple inheritance in a lot of cases specifically _because_ I
want
>to inherit implementation, I think (I'm not good with terminology, so
precise
>explanation here would be useful ;)

Inheriting implementation is the problem.  When you inherit implementation,
you have two pieces of software (base and derived classes) that do not have
a clear contract between them.  What is the base class responsible for and
what is the derived class responsible for?  What happens when you inherit
functionality from the same class along two different lineages?  I guess
these are the collisions that you're trying to resolve.

Inheritance in the systems that we were working on was used once: all
interfaces inherited from IUnknown.  The IUnknown interface is almost an
infrastructure mechanism.  Other than that, we just defined interfaces.
There was a composition technique used to take multiple interfaces and bring
them together, but I'm not sure whether I'm stepping into proprietary
knowledge or not now.  Certainly most every one of the bits and pieces of
techniques and knowledge used had been used elsewhere, but I don't want to
go near the stuff that struck me as the meat of the research.  Suffice it to
say that it was not inheritance.

Whenever you think inheritance, think composition instead.  What if, instead
of inheriting some chunk of functionality, you built it into a
self-contained service component that provided the same functionality?  That
service component now has to have clearly-defined behavior that anyone can
reuse.  Further, you can use that service component multiple times in the
same component for different purposes.  That is, you can create multiple
copies of it for your different purposes.

>I have books on COM and CORBA, I've implemented CORBA and XMLRPCish
solutions
>to thing - but I haven't the names or experience you hold.  So I'll bow to
a
>higher understanding than mine, but I'll note that for what we're doing,
>multiple inheritance and inheritance of the implementation of various small
>aspects of things is really elegant so far - easy to understand, easy to
work
>with, extremely flexible.  Agreed for certain things it doesn't fit, but
then
>for certain things components add a level of complexity that doesn't appear
>warranted.  Multiple inheritance in this environment just seems to "make
>sense".

Think of implementation inheritance as a poor-man's component system.
Inheritance systems tend to have a fairly compact notation for the
compositions, and they are accomplished by 'inheriting' implementations.
But that's what a component is - an implementation (of a specific behavior).
Your comment about added complexity is off the mark, I believe.  If I give
you a component language and some starting components, you'll be like a kid
in a candy store.  Or perhaps I should say: a kid in a lego store  :)

JB

P.S. My apologies for name-dropping.  I just don't usually get to do it :)


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev