[MUD-Dev] Object Models
KevinL
darius at bofh.net.au
Fri Nov 17 14:15:45 CET 2000
>>> Dmitri Zagidulin wrote
> On Thu, 16 Nov 2000, J C Lawrence wrote:
>
> > What you are talking about is called "multiple inheritance". It is
> > not an entirely trivial topic, and in fact has a number of very ugly
> > aspects. Its worth spending some time reading up about multiple
> > inheritance and single inheritance via your favourite search engine.
>
> Question for you guys - when do you actually _need_ multiple inheritance?
> I can't think of an example where one would need multiple inheritance
> which couldn't be elegantly expressed (or at the very least expressed
> without much extra effort) as using regular inheritance with components.
> Can you think of one?
I tend to think of it more as a stylistic thing than a "we need x" -
having multiple inheritance opens up a couple of patterns that are
easier that way than others - for instance, I sent a post earlier
that described combining steel, chest, and lockable objects as
parents to create a lockable steel chest object. Maintenance of the
various "aspects" or "attributes" or whatever you want to call them
becomes so much easier - if you want to introduce a new sort of
magic, and make steel subject to that, you change steel and
everything steel changes.
The other example, that of a creator object that holds all creator
utilities and can be added to any other object's inheritance tree to
make them a creator, is also an easy pattern under multi-inheritance
- not needed, but somewhat elegant ;)
Regular inheritance with components will get you close to that, but
not necessarily all the way. Of course, you _do_ pay a cost in
complexity, but I tend to view multi-inheritance as a superset of
regular, so I support multi, and leave it up to the mud admin as to
whether they use it or not. The policies for inheritance are
stated, and deterministic, so it's really an "if you like it, use
it, if not, don't" kinda thing.
KL
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list