[DGD] parse_string implementation of restore_variable()
bart at wotf.org
bart at wotf.org
Wed Oct 29 20:09:06 CET 2008
On Wed, 29 Oct 2008 10:50:20 -0700, Shentino wrote
> Are you sure you don't want to handle nil?
Yes, I am absolutely positively sure of that.
1. this is not a matter of what *I* want but of implementing something
compatible with other existing implementations that are outside of
my control.
2. the 'spec' does not handle nil, since the other side of a mudmode
network connection does not handle nil, and will never ever send nil.
So, there is a really good reason to not support it, it is simply incompatible
with the rest of the world, and communicating with the rest of the world is
the primary reason for having written this.
>
> What about arrays with object or nil elements?
mudmode data streams are used for communications between muds.
Object references that make sense on your local mud usually don't make
sense at all on a remote mud that very likely doesn't have the
same objects loaded, and if it does, can't guarantee that they have
the same objectid (including instance number), and very very very very
likely (like currently 175 out of 1) the remote mud isn't even using
the same lib or driver.
So, sending object references over a network connection is simply not going to
work ever unless you change the entire world and make a system of universally
usable objectids. That is an interesting idea, but totally and completely
outside the scope of this little project, and an impossibility since I am not
going to rewrite every other lpmud to deal differently with objects, even if I
could.
For local communications, objects can make sense, hence I may well add
support for them at some point, but you still have to guarantee that the
object wasn't destroyed and another object with the same id took its place.
There is a pretty good reason why save_object() does not save variables of
type object, it applies here as well.
Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/
More information about the DGD
mailing list