[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

15842: RE: [MUD-Dev] Object Models

[Full Header] [Plain Text]
From: "Joe Andrieu" <joe@andrieu.net>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 28 Nov 2000 09:16:15 -0800
References: [1]
Organization: Kanga.Nu
> -----Original Message-----
> From: mud-dev-admin@kanga.nu [mailto:mud-dev-admin@kanga.nu]On Behalf Of
> John Buehler
> Sent: Monday, November 27, 2000 9:37 PM
> To: mud-dev@kanga.nu
> Subject: RE: [MUD-Dev] Object Models

[snip]

> 1. You have an error handling case where an object cannot be sharpened.
> This is an example where strict contracts and strong typing prevent the
> possibility of that happening.  A component that cannot be
> sharpened can't
> even represent itself to the sharpener.  The sharpen method requires that
> the component passed to it be an 'edge' component.  This would
> be checked at
> compile time, not runtime.  This is one reason why weakly typed languages
> are a pain in the backside.  Error handling was called "One of the four
> unsolved problems in software engineering" by one of our
> consultant types.


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

-j

--
Joe Andrieu
Realtime Drama

joe@andrieu.net
+1 (925) 973-0765


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