[Home] [Groups] - Message: [Prev in Group] [Next in Group]
15854: RE: [MUD-Dev] Object Models
[Full Header] [Plain Text]
From: "John Buehler" <johnbue@msn.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 28 Nov 2000 15:26:27 -0800
References: [1]
Organization: Kanga.Nu
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@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev