[MUD-Dev] Object Models

[John Buehler]

Miroslav Silovic writes:

> 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:

How is this different from having a component that implements a Sharpen
contract and contains the sharpness attribute?  Anything that is sharp would
incorporate that component into itself.

Components require significant infrastructure to be easy to use.  And I
think this is why they generally don't work.   Managers can't just say
'Okay, we're going to build this application using components' when all they
have available to them is C or C++.  That's just not enough infrastructure.
Other sets of infrastructure are easier to make, and as a result many other
approaches to the problem of application construction have been implemented.

JB


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