[MUD-Dev] Object Models

[Bruce]

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.

Being somewhat familiar with TOM, some other aspects of this that
Miro didn't mention are:

 * The extension of a class by another (like adding
   Sharpen to EdgedWeapon) can happen at link time.
   Due to a limitation in the TOM runtime implementation,
   if Sharpen needs to add instance variables, it
   can't be loaded at runtime to extend the class.
   Otherwise, that would be possible as well:

   [Bundle load "myextension.so"];

   As mentioned in Miro's other post though, as in CLOS,
   it may be possible to address this, depending upon
   the impact on execution speed.  Of course, it can
   also be done at compile time.

 * 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.

 * 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.)

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