[20] in Coldmud discussion meeting

looking into the future

daemon@ATHENA.MIT.EDU (Tue Nov 16 04:19:34 1993 )

Date: Mon, 15 Nov 1993 22:43:29 -0600 (MDT)
From: Lynx <BRANDON@cc.usu.edu>
To: coldstuff@MIT.EDU
X-Vms-To: IN%"coldstuff@mit.edu"

Just some ponderings on merging core's

First off it should be much easier with ColdMUD, as you dont have object
numbers, just dbref's.  From here you can probably write up a perl or whatever
program which takes the textdump and basically takes each object, checks for
.core, extract all .core objects to another work file (less overhead) and then
does some matching/diffing/etc on each core object, with the new ones.

Now, EVERYBODY modifies their own core, this is a known fact.  It would really
suck to rewrite an old core method with some brilliant new method, only to have
it written over by somebody else's brilliant new method.  I say we do the
following with core objects, and releases.  first off:

keep a copy of the old core around (you want to release both old, and new, so
the program can tell what has changed in comparison to the one it is trying to
merge with).  Then, with each core method have a statement at the end such as:

// **** CORE METHOD ****

then if it is ever modified this statement is removed.  Then when the merger
comes along to update to spiffier methods it first checks for this statement,
if it cannot find this statement it creates <method>2, so that the gods can go
back after the merge and diff each method to see which is better, modifying it
from there.

I'm still trying to figure out what to do with parameters...

-Lynx/Brandon/Me.  (just some thoughts, like I said)

Oh, make some comments, if I dont hear any major negative flammage i'm going to
start adding // **** CORE METHOD **** at the end of each core object