[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

John Buehler wrote:

> Oh, I think I get it now.  There are no component design tenants.
> The size of a component is up to you, and the abstraction distance
> from the raw functionality that you are accessing is up to you.

Uhm, but if so then there is no such thing as component design...? 
Sure you can tweak OO and structured programming and what not to fit
your needs, but...

Again, I do see that components make sense in some areas, just not in
the MUD core.  Except maybe if you have a frozen design and need to
speed up development using an incremental strategy (as opposed to an
evolutionary one).

Isn't it true that the further you go towards pure components, the
closer you get to the waterfall model (which was specification based!)
and structured programming?  That's how I see it anyway.

> And you would be creating a component as soon as you construct that
> module.  You don't call it a component, but it is.  And you won't be
> managing the contracts that relate to it very strictly, and that
> will burn you whenever you blink or lose concentration while working
> with it.

And that can't happen with components? :)

(I do use invariants and produce code to check them where possible.
Unfortunately I don't get to program a whole lot, but when I do...)

> The first component does general collision detection.  Then when you
> only want an area spell that affects level 40 dwarves, you construct
> a new contract and a new component.  Fortunately, you have a general
> purpose collision detection component that you can use for the
> lion's share of the work (through aggregation or delegation, not
> code reuse).

So now you have a less efficient design with additional methods you
could otherwise have avoided. With lots of interdependencies, it will
become pure hell to specify useful pre and postconditions, not to
mention reading and updating them :). You may of course reduce what is
covered by the pre/post conditions, but then they become less useful.

To cut down the searchtime you basically need to let the spatial
datastructure "know" more about the objects and structures that
contain information about them. (for instance, by storing avatars and
other objects in separate sets, knowing somehow that objID x is a
dwarf is an avatar or possibly knowing intimately about other
datastructures that is maintaining information about objects) But the
more units know about each other the less component based the design
becomes...

> To obtain an interface requires a call and a simple lookup to
> retrieve a pointer.  To make a method call, a pointer dereference
> and a procedure call are the overhead.  To the best of my knowledge,
> it's the same overhead as C++ (actually COM was required to being
> compatible with Microsoft C++).  If you go with fine-grained
> components, you can accumulate significant call overhead.  If you go
> with coarse-grained components, the call overhead is limited.  Which
> is, of course, the same equation as for any pile of code.

Except that with components the idea is that everything should pass
explicitly through a clean-cut interface. In practical decent C++ code
you do use a lot of inlined methods and templates and try to reduce
the number of virtual ones. Wherever you know what class you are
calling you don't really have to go for a virtual one anyway...  I
like shallow class hierarchies.

--
Ola  -  http://www.notam.uio.no/~olagr/

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