[MUD-Dev] Object Models

[Chris Gray]

> From: "John Buehler" <johnbue at msn.com>

> 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.
> I forget what the other three are  ;)

I've only been skimming the emails on this subject, but this bit caught
my eye. I believe that a system like a MUD shouldn't be "compiled". By
that I mean that it shouldn't, at its top levels, be fixed at compilation
time as to what attributes and operations exist. This does *not* mean
that I don't believe in strong typing. I do. My MUD language is strongly
typed. With one exception: an object need not have a given attribute or
operation available. Code can check, at run-time, for the presence of
those things, and so make reasonable default assumptions. So, the test
for being an "edge" can be made at run time. It need only be made in those
places that require an "edge" thing to work with. The big advantage to
doing this at runtime is that new attributes and operations can be added
to an already running system, and, with proper checks and defaults, can
work reliably with all things in the system, even given that those things
have no knowledge that they are being checked for this new operation that
they've never heard of.

I think this kind of flexibility is quite important for long-running
on-line systems like MUDs. Allowing them does not require throwing away
strong typing at compile time. It just needs a simple escape mechanism
by which checks can be done at run-time for the presence/absence of
the attributes and operations involved. See the AmigaMUD web pages on
my site for much more detail on what I mean.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev