nu.kanga.list.mud-dev

15843: Re: [MUD-Dev] Object Models

"John Buehler" <johnbue@msn.com> writes:

> There is no question that applications can be built using a variety
> of techniques.  I'd be very interested to see how folks felt before
> and after working with components in the form that I was working
> with them.

Hmm, coming from LISP backgrounds, the components left me VERY
unimpressed. I'm currently working with TOM that allows any module to
touch any class, anywhere else in the system (however, it fixes the
potential pitfalls with pre/postconditions, so you still can specify
the contracts).

This is VERY useful. To return to the example, now you can code
sharpening as a module that's completely orthogonal to the rest of the
system:

implementation class Thing extension Sharpen end;

implementation instance Thing extension Sharpen

void sharpen
{
    /* arbitrary thing can not be sharpened */
    /* raise an exception */
}

end;



implementation class EdgedWeapon extension Sharpen end;

implementation instance EdgedWeapon extension Sharpen
{
    /* additional state */
    int sharpness;
}

void sharpen
{
    /* Do something here */
}

end;


implementation class CommandParser extension Sharpen

/* ... */

end;



implementation instance CommandParser extension Sharpen

/* ... */

/* trap the sharpen exception here! */

end;


Now you only publish the command interface extension but not the
weapon behaviour extension.

With this, you still end up checking things at runtime, but you *do
not have a contract that specifies it*, because the behaviour is
private to the module!


--
How to eff the ineffable?
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev