[MUD-Dev] Object Models

[John Buehler]

Travis Casey writes:

> Not being a software professional, I'm not sure what the distinction
> between "tight" and "loose" contracts is, so maybe I've only dealt
> with loose contracts.  In the contract models I've seen, though, a
> contract only specifies what must be supplied and what must be done --
> it doesn't specify that an object can't have any other data or
> behaviors other than the contracted ones.

A contract, categorically, makes some statement about what a method must
accomplish.  A contract can state pretty much anything, including the
statement that nothing more than what has been stated may be changed.
Normally, the latter statement is not made due to the design restrictions
that result.

A 'loose' contract might best be presented by the statement 'and then a
miracle happens'.  It's just a statement that something happens, but you're
not being very specific about what happens.  A 'tight' contract makes very
specific statements, such as certain parameters and component state changes
in carefully-defined ways.  This can be very useful if you want to ensure
that the system that you're building has some kind of useful behavior.  More
knowns, fewer unknowns.

Imagine the 'loose' contract in construction of a fastener as opposed to a
bolt, screw, rivet or rubber band.  If you order 1000 fasteners from a
supplier, who knows what you'll get.  The tighter contracts of bolt, etc,
are still pretty loose.  Would you just order 1000 bolts?  You still don't
know enough for your purposes.  So you order certain length, shaft, thread,
etc bolts.  That's a tight contract.

> Thus, changing what all a low-level component will do (e.g., to add a
> "temperature" variable and make the "sharpen me" behavior take it into
> account) doesn't mean that you'll necessarily have to change all the
> code that uses that component.

Loose contracts give you room to add behaviors, but it also limits the
things that the client of a contract can rely on.  If you have a component
that has temperature and a component that doesn't, yet the 'sharpen'
contract makes no statement about the need for temperature information, you
may get some unusual behaviors that you don't want.  For example, some
blades might sharpen more easily on a hot forge, while others will not.
This will be confusing to users.  The value of tight contracts is knowing
what you have - and knowing when you're making changes.  You have to
acknowledge the fact that you're changing the relationship between
components and to consider what impact that has on each element of your
design.  Without it, you end up with screwy behaviors, which are bugs just
as much as a crash or having the wrong texture on a surface is a bug.

> The usual problem that I've run into with adding things like that in
> muds isn't updating objects that use those components -- it's going
> back and changing everything that's already finished that *should*
> have used those components.

One of the things that a solid set of component tools addresses.  This was
what my research team was working on when I left.  It was the last paper
that I wrote before leaving.

I'll skip over the various modelling issues.  That's something that requires
a ton of investigation.

JB


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