[MUD-Dev] Object Models

[John Buehler]

Joe Andrieu writes:

> Checked at compile time?
>
> I think a lot of the systems we are talking about require (or benefit
> greatly) from run-time modifications, where I don't believe "compile time"
> solutions address the needs of maintaining a live codebase.  The code has
> to work even if error-checking happens when it is called in realtime by an
> object it has never seen before.
>
> I can see that if I have all my components lined up and compiled for a
> traditional application, a la Office 2000 that we have lots of ways to
> check for compatibility amongst components.
>
> So, how do components handle the case where a *live* object has a
> component
> modified?

I just replied to another post along these lines.  The short form is that
what you call making changes at runtime is simply making changes such that
there isn't a discrete compilation and link process.  Changing a running
configuration of statically-defined components is just as tractable as
modifying a running system in place.  They'll both boil down to the same
results.  A system that is designed to be upgrade in place is going to be
more straightforward to upgrade than a running thread of a typical operating
system.

> I could see writing update code to swap and test the component in every
> object out there that has the old component. That is probably a tighter,
> safer mechanism than automatically updating the functions of all ancestors
> of an inherited class. But it sure does seem more of a bother, which means
> that while the code base may be tighter, the pace of innovation is
> significantly lower.
>
> Am I understanding your comments correctly? Or is there a different way
> components can play a role in large-scale run-time-modifiable environments
> where inheritance has proven a reasonable solution?

No, I think you've hit upon something that would be a practical challenge to
implement.  As I stated, it's DOABLE, but getting the infrastructure in
place would be interesting.  Existing instances of a component are
represented by a one-time load of code and many little (hopefully) chunks of
memory floating around.  If the memory sixe increases, that's a real
challenge.  But if it's just code changes or the memory layout is altered or
shrunk, I think it's completely practical.

An alternate approach is to let NEW instances of the component use the
modified component.  This may be satisfactory, but maybe not.

By the way, in the methodology we were using, modifying a deployed component
results in a NEW component.  There is no observable relationship between the
old and new.  It would be just the same as swapping out a component that I
wrote with one that you wrote - so long as they implement the same
contracts.

JB


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