[MUD-Dev] (no subject)

[John Buehler]

>From: KevinL <darius at bofh.net.au>
>Date: Thu, 16 Nov 2000 19:40:57 +1100

> >>> "Ben" wrote
> >     Okay, I am aware that a) this may have been discussed prior, and b)
it
> > may go a little to far into technicalities, however I feel that this is
a
> > very controversial subject in the minds of many programmers, as it has a
> > major impact in the way the MUD is engineered.
> >
> >     Now what I am wondering is how you all handle the objects in your
MUD.
> > The two camps that I am aware of is the strict old style method of
> > definining every single object.  The alternative camp is that which
feels
> > that you should have multiple types of objects, and then have each
object
> > dynamically inheriting the properties that pertain to it.  The problem I
>
>We do this! :)

  I'm just jumping into this discussion.  I'm not really picking on Kevin or
Ben.

  Try this:  create components that implement well-defined behavior and
stick 'em together to build up bigger components.  One example presented was
a room with a door and a room without a door.  What about a room with two or
more doors?  Adding a door is a construction issue, not one of inheritance.
Inheritance really isn't needed in most cases.  And I'm talking about one
contract (set of behaviors with a given virtual table of functions)
inheriting its definition from another contract.  That kind of inheritance
is rarely needed, while inheritance of implementation is never needed.
Create components from other components instead.  That way, all contracts
that exist in the software system are actually materialized instead of just
being a vaguely understood relationship between a base C++ class
implementation and the derived class.

  I spent two years working at Microsoft Research with Tony Williams
(inventor of COM) and Clemens Szyperski (author of "Component Software :
Beyond Object-Oriented Programming" and who is also a 'name' in the
component world) and had my eyes opened to what component software can do
and why the C++ implementation-inheritance approach is giving engineers lots
of rope to hang themselves with.  Take some time to learn about component
software and about strict contractual software development.  I believe that
it's the future of software.  I'm very pleased that Dmitri brought up his
'atomic functions' topic because that goes hand in hand with where software
must go in the future.  We will need transacted methods if we want to have
the high quality reusable software that is one of the holy grails of the
software world.  Funny how the database guys have known this all along...

  FYI, COM+ has nothing to do with what I was working on.

JB


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