Random thoughts

[Jon A. Lambert]

> 
> More or less, yes.  However, don't assume that the basic object has any real
> definition.  It doesn't.  It doesn't even have a default set of attributes and
> methods -- all of that has to be defined in the MUD language.
> 
Aye, I have been playing with ColdX/Genesis for the last 2 weeks so
this concept is clear to me now.  I've got it running on Linux and have
the compiler running on Win95.  I am very close to having the driver
running on Win95 :-)
I would think that it would be easily portable to OS/2.  I have the execution
commands currently disabled since they use fork() which I will later replace with
CreateProcess().  I found a DOS port of GDBM out on the net which easily
recompiled into a WIN32 lib.  Other than some Borland intricacies there were
relatively few errors.   
My first impression of ColdC is much better than LPC.  ColdC seems to be
more austere than LPC but just as powerful.
I am not sure how all this relates to my in-progress server since the concepts are
quite different.  My server has a decidely DIKU bent .  I am toying with the idea
of attempting to program some of my existing servers' objects into ColdC.
The online programming seems quite awkward to me right now.
Anyways, if you have any thoughts on ColdX, I'd sure appreciate hearing them. 

> 
> How does this handle the Dragon's Dinner scenario, ala:
> 
>   Transaction A checks value X (read, no write, thus no lock), and on that
>   basis, changes object Q to state Q`.
> 
>   Meanwhile, transaction B modifies value X to state X`, and commits prior
>   to A committing.
> 
>   Problem: Logically Q` and X` can't exist at the same time (eg the door is
>   closed, _and_ there is a wind blowing through it).
> 
> It would seem without some checking of read-locks that its a gaping hole.
> 
Yes Autocommit is useless to your scenario.  Although relational
technology does handle this scenario quite well.  In the commercial
environment read/locks are avoided like the plague.  I've worked on a
number of inventory systems where your 'dragon dinner' scenario can
and does occur.  It is generally a risk assesment vs performance issue.
Read/locks are really bad if you come upon a wait condition ( ala user
input).  The other conditon that comes up frequently is in locking multiple
objects.  If you come across an object that is locked by another 
transaction you must, in most circumstances, release all your locks
and start over or cancel.  Otherwise deadlocks can and will occur
between transactions that need to get at 2 or more objects in common.

Now in this particular example, read/locks should work.

1) dragon and player both attempt to read/lock exit/door object.  
2) first one to the lock wins.
3) If the dragon wins, he releases his lock after he has
   traversed the door.
4) If the player wins he releases the lock after the door is slammed.

I would guess if the dragon wins, the player still completes the door
closing?  Or you could fail the door slam request based on the failure to
get a lock?  If you fail the door slam, do you retry?  It would have side 
affects for multiple characters attempting to walk through doors at the
same time. 

> I've thought long and hard about adding a "friends" concept to my inheritance
> model, and have yet to come up with a compelling reason to.  There are too many
> other ways about that particular bush to pervert my almost perfectly closed
> objects for.

I would avoid it if at all possible. It might also expose a security risk in 
'user free' programming since your security checks may be compromised.  

> > > Please don't tell me that you have a polling loop!
> >
> > Gasp! Yes!  I take it this is bad?

Thanks for the info.  I discovered the magic of the event object courtesy
of Borlands TEvent Class.  Its working quite nicely and elegantly now. :-)