[MUD-Dev] Object Models

[Bruce]

John Buehler wrote:
> Bruce writes:
> > Miroslav Silovic wrote:
> > > 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.

Ask away.  There's plenty for everyone to learn in this thread.

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

It is a notational technique that is integrated into the design
and implementation of the compiler, language, and the runtime
libraries to provide for a way to re-use libraries in the face of
many obstacles. (Like not having source, bugs present within the
libraries, etc.)

Miro and I have been using it in a somewhat different form though
to separate out different aspects of objects and their behavior
into clear and concise pieces, which are then grafted back
together and form a single class.

The end result ends up being largely the same.  I'll have
questions down below about how you do this in your system.

But, if at some point, we decide to remove an interface, all that
we need to do is remove one of the files that implements our
extension to the rest of the system from the build system and
re-build the relevant library, and we've now removed that
entirely from use.  We didn't have to go crawling around lots of
places and remove bits and pieces from here and there.  This is
somewhat similar to some of the tools that exist for Aspect
Oriented Programming and Subject Oriented Programming which allow
you to isolate chunks of code that cut across a number of classes
into a separate set of files, which are then put together by the
tools (like Aspect/J).  Of course, I can't speak to how this may
or may not be similar to the tools that you are using.  Maybe
your tools do all of this for you as well?

> That is, the interrelation of type information between
> chunks of software.

Missing a verb? I'm not sure what you're trying to say.

> Perhaps I should simply read up on TOM.

Possibly.

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

If all tools were so perfectly safe, we'd have no recourse when
we actually needed to do something.  What would happen if we
should need to binary patch a component out in the field?  Say,
we have a running server, but we don't want to have downtime.  We
need to quickly replace a buggy piece of code.  Without the
ability to perform runtime loading of code, how would you propose
that the code be replaced without incurring downtime?  Try to
avoid the temptation to respond that downtime would be preferable
to taking the chance that one might hang themselves by having
this type of freedom. :)  It is the job of a software engineer to
know what their options are, what the problems are and to come to
an appropriate choice.

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

So, how exactly are you composing these interfaces?  What
mechanics are you using?  Is this C++?  Are you using some custom
tools?  How are you writing contracts?  What are contracts
written in?  Can you provide an example?  Is this tool something
that we can look at?

> 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

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

Well, explain!  I -know- that I won't believe "no bugs".  After
all, if the tests claim there are no bugs, I don't think I'd
still trust it as I don't know if:

 * Tests were incomplete
 * Underlying system problems (can't do much about this)
 * Tests were bug-free
 * Testing harness was bug-free
 * Did the tests cover data input? Did they
   account for a malicious user? Did they cover
   all of the relevant cases there? (Can they
   cover all of the relevant cases?)

(But, I do believe that testing and automated test suites are the
only way to be assured that something does indeed work.  But, I
still assume that it has bugs.)

As an aside, it often isn't clear that you've seen what you're
saying actually work:  "He wanted components to be absolutely
opaque."  Were they?  If not, why not?  If so, how did the people
using those components fare with them?  Did they run into
unexpected behaviors?  Was everything completely clear to them
from the documentation and the contract?  Did that include the
memory usage patterns and performance profile of the component?

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