[MUD-Dev] Object Models

[John Buehler]

Bruce writes:

> Miroslav Silovic wrote:
> > "John Buehler" <johnbue at msn.com> writes:
> > > 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.
> >
> > It's different in that anything that is sharp does not
> > need to incorporate this component any more - it inserts
> > itself into places that need it. This means that the
> > component doesn't have a public interface - most of its
> > interface is simply its existence in the application.

I didn't want to say much of anything in reply to this because I honestly
didn't understand the difference.  Terminology woes.

What I'm seeing suggests to me that there is some notational or procedural
technique that gets additional functionality into the desired classes.  I
just don't see anything topologically different.  That is, the interrelation
of type information between chunks of software.  Perhaps I should simply
read up on TOM.

>  * The extension of a class by another (like adding
>    Sharpen to EdgedWeapon) can happen at link time.

It sounds like TOM is geared for giving the engineers lots of rope so that
they can do whatever they want, whenever they want.  That is, lots of tools
and options and such.  But I really do think that it sounds like a lot of
rope to hang one's self with.  Obviously, it lets you do what you want, but
I have my doubts as to whether you really want to do that.

>  * Generated documentation for each class need only
>    cover those items that are particular to that class.
>    Shared aspects of classes and behavior, when
>    implemented through the extension mechanism, would
>    also have generated documentation that covered only
>    what was necessary.

With what we were doing, the lion's share of documentation lay in the
interfaces that components implemented.  So whenever a component was used,
the existing interface documentation could be referenced.  When a component
brought together multiple interfaces (perhaps from multiple subcomponents)
such that they relate to each other, a new 'type' contract needs to be
written to express that interaction.

>  * When looking for the code involved with something,
>    you need only look at a set of files which contains
>    all parts of the implementation.  You don't need to
>    root around throughout the source tree trying to find
>    all of the places which have integrated in code.
>    Instead, they should all be in one spot, implemented
>    as extensions to the other classes.
>
>  * I might not have the source to something that I want
>    (or need!) to extend.  (Or, it might be source that
>    is under the control of a different party, with a
>    release schedule that doesn't coincide with my own,
>    and I need the extension to the object to be there
>    in my release, before their next release.)

In our component approach, the development manager liked to use the phrase
"throw away the sources" for what to do when a component ships.  He wanted
components to be absolutely opaque.  There's no need to see into a component
for integration purposes because you integrate at the level of public
interfaces (a runtime consideration), and there's no need to see into a
component for debugging purposes because there are no bugs (you wouldn't
believe the verification process).

JB


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