[MUD-Dev] Re: TECH: Distributed Muds

[Vincent Archer]

According to Bruce:
> Vincent Archer wrote:

>> A friend looked at what we were trying to do and said: "it's a
>> trap".  Because you no longer know that objects are now in fact
>> stored on disk, and not resident in a process memory, you quickly
...
> But, in the end, that's something that you're constantly aware of
> when programming and something that you can monitor easily.
> Depending on

Therein lies the trap. You see the whole purpose of OO databases is,
like most object oriented design, to remove the underlying constraints
and limits from the view of the programmer.

My friend told me "it's a trap" because he was in a development team
that *fell* into that trap. The OO database hides you all the nitty
gritty details of database management, so you quickly ignore the fact
that this or that object is in fact stored on disk. That referencing
this pointer will in fact call a whole method who first determines if
an object is or not in memory, find it somewhere on disk, allocate
memory... just because you wrote:

	if (myinventory->mainfood == Extrafeast)...

Sure, his dev team wrote a working application in half the time they'd
have needed if using a classic relational database. But then, they had
to spend probably three times that rewriting the application to catch
all the hidden places where assumptions clashed with reality, because
the assumptions all looked natural. In fact, they're still at it, from
what I heard.

That's what I was illustrating in my example. Hiding "things" from the
programmer to help him concentrate on "more fundamental" issues is
nice.  But be careful: sometimes, the things you forgot come back to
bite you with a vengeance :)

--
Vincent Archer                                         Email: archer at nevrax.com

Nevrax France.                              Off on the yellow brick road we go!
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev