[MUD-Dev] (no subject)

[Dan Merillat]

KevinL <darius at bofh.net.au>
> But then when you built a bunch of cars, would you use the four-wheeled 
> vehicle as a component and write more wrapping code, or would you just inherit 
> from the four-wheeled vehicle and make local changes as necessary?


It's all how you think about it.  Cars, busses, trucks, motorcycles... they are
all 'vehicles'.   They also have differing amounts of the same base components,
engines, wheels, axles, seats, shocks, gas tanks.  So a vehicle defines the
interface for dealing with a car, and the specific child of vehicle handles
the management of it's specific components.

Car and Truck are siblings, not parent/child.



To go back to a MUD example, inheriting doors.  My object tree works something
like this:

A room object dosn't need
to know about doors, it only needs to know about movable_directions (abbreviated
to 'exits')  the exits interface gives you access to exit components of a room,
the default (an exit) having a method to transport you to the adjacent room.
a door (inherits an exit) only transports you there if it is open, and defines
an open/close interface/lock/unlock interface.   an exit can also be parent
to a turnstile, which works just like an exit but counts the number of people
passing through it.  Or, a trap.  Or anything else you can come up with.
But putting all that code in the room object seems... ugly.
 
> I'm seeing overlap, but I''m still thinking that inheritance is a useful 
> concept.

It is.  But the difference is all in where the wrappers go.

If I've got two similar things (A key and a breakable key), obviously I would
inherit one from the other.  breakable key inherits key, overrides 
unlock(door &) to be:

	Key::unlock(door);
	break(me);

However, if I have two things, a monster and a key... now I create a
key_monster by multiple inheritance.   That means my parent (a thing) has to
know (wrap) both key class and monster class.  With components, you don't have
to wrap, code that wants to unlock a door calls thing->key->unlock(door).   The
parent inherits null components, so null_key.unlock() returns false.

See the subtle difference?  The default code for a key is now in the key module,
which can be changed without affecting the main object at all.   Whereas with
multiple inheritance, the base lock/unlock code has to be defined by the
parent object.

For our typical example (key monster) your monster component becomes
a monster_with_key (inherits from monster) and key becomes key_as_monster
(inherits from key) and override anything important (unlock causes the monster
to attack, teleport elsewhere, whatever)

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