[MUD-Dev] Object Models

[KevinL]

>>> Travis Casey wrote
> Monday, November 27, 2000, 1:44:49 AM, John Buehler <johnbue at msn.com> wrote:
> > Travis Casey writes:
> 
> [snip explanation of "tight" vs. "loose" contracts]
> 
> >> 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.
> 
> I think this is getting to a different point than I was talking about.
> Let me see if I can be clearer:
> 
> A contract specifies what must be supplied and what must be returned
> -- but there's nothing in the idea of a contract that requires that
> everything that is supplied be explicitly passed as a parameter.  This
> leaves room for later revision of contracts without necessarily
> changing the code interfaces.

Ah, but I've never seen a contractual system that allows for stating 
requirements on the "client" or user in that way - it's non-enforceable, you 
can't stop an object that doesn't live up to the contract from attempting to 
use the component (in any language I'm aware of).

John's suggesting something much tighter, I suspect - which is where he and I 
part company.  I am a believer in a looser coding style, possibly closer to 
the XP stuff, in cases where code is expected to change frequently and you 
don't want to have to go back and touch everything to change a component.

In muds, especially in "under development" muds (as opposed to all those 
stable static muds that have finished being worked on *grin*), code _does_ 
change, and in ways like my example - adding new skills that rely on new 
attributes, adding new stats to objects, so on and so forth.  My approach to 
this has been simply to write code that attempts to use the new attributes/
methods/whatever but does not bomb out if they're not available, and more 
importantly allow for a default "flow-through" mechanism in the form of 
inheritance, so attributes can be added to _everything_ (or a reasonable 
subset thereof) very quickly.

I never saw a clear answer to this, but I believe if you have a blade 
component and you add an isSharp() method, you're going to have to revisit 
every object that uses that component and explicitly deal with that addition - 
_or_ you're going to have to find every place that might check if an object's 
sharp and refer to object->blade->isSharp().  The first concerns me because of 
the level of upkeep for what I'd consider common operations, the second 
concerns me because it breaks the "what if we've got two blades" assumption of 
components somewhat - you're breaking down the object-ness of objects by 
making assumptions for them about their structure.

The more I think about this, the more I'm convinced that components have their 
place, but probably with loose contracts - which'll make John cringe ;).  
Tight contracts are _one_ approach to getting good code - but they are, to me, 
an approach that follows the previous attitudes of "make it more explicit, 
make it harder rules, and it'll be more likely to be right", which I don't 
believe.  Loose contracts and loosely-typed scripting, a la python, combined 
with heavy/fast testing cycles a la extreme programming, may be a more 
suitable approach for muddish coding, maybe ;)

KevinL

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