[DGD] happycode in DGD
bart at wotf.org
bart at wotf.org
Sat Sep 7 12:19:06 CEST 2013
On Fri, 6 Sep 2013 17:34:37 -0700, Raymond Jennings wrote
>
> Similiarly, by checking the new control block and making sure that no
> functions disappear that are needed by the happycode objects. Local
> function calls remain, and continue to point to whatever functions replace
> the ones that they referred to. Kinda like undefined function resolution
> during runtime. In fact, if I treat it as a call to an undefined
> function, I might not even need to check this during recompile. It
> might be a good debug tool though.
>
> Also, happycode snippets are NEVER recompiled, ever. When I
> recompile a master object, I generate brand new happycode objects,
> and leave the old ones behind for outstanding fp's to point to.
Well, working code tells me more then long design mails, make something and
see if this is workable.
>
> Of course, everything would be much simpler if happycode blocked recompiles
> outright, but then where's the advantage in porting to dgd?
Personally I think the hassle of actually implementing this without too many
restrictions is much bigger then the hassle of rewriting code that uses
'happycode' and not worth the time and effort. Why?
There are essentially 2 mudlibs that are in wide use still that would benefit
from this (Discworld and Dead Souls), but that will require a lot of work to
port anyway, especially if you want in-place recomplilation to work, it will
cause a lot of refactoring of code and moving things around. I'm absolutely
not convinced that either lib will actually get ported to dgd once 'happycode'
works, rather, I'm convinced neither will get ported. Why would they want to
spend time on porting when already not having enough time to address all
functional issues to begin with. Matter of priorities of course, but for most
such muds technical correctness isn't exactly a priority at all.
I'd suggest to only consider pursuing a plan like this if you have yourself a
direct need for it, are going to port a lib yourself, and would like to have
others benefit from your efforts. Else the chance is pretty much 100% that it
will end up like Felix' function pointers, you add it, noone will look at it
for another 2 years, and then someone comes along who actually checks it
functionally, and then forgets about it again.
Bart
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/
More information about the DGD
mailing list