[crossfire] 2.0 object-type refactoring

[Alex Schultz]

Mark Wedel wrote:
> <snip>
>
>   IMO, I'd prefer the second form - put the types directory at the top level, 
> relative to the server directory.  This is how the socket code is, doesn't have 
> any real disadvantage, but could have some advantages (better for unit tests? 
> Better for stand alone program that does simulations, etc?)
>   
I was originally thinking of as a subdirectory of the server directory
as in the first form, but now that I think of it, what you suggest I
think is a bit better.
> Function pointers:
> It's not specifically mentioned on how the callbacks are registed.  I see one of 
> two ways:
>
>   register_apply_callback(type, funcpointer);
>
>   or
>
>   register_callback(type, funcpointer, callback_type)
> <snip>
I'm currently thinking of using the first form, largely so it matches
what I plan on using for calling the callback itself. I decided on using
ob_apply() ob_drop() instead of my old idea of cf_method(ob, type, ...)
primarily due to compiler type checking.

>   It's also not really mentioned on how the callbacks themselves are registered 
> (that code has to be someplace).  And rather than having a single function that 
> registers all the callbacks for all the object types, I'd suggest that each type 
> file has something like init_callbacks_weapons (or something).  Then in some 
> other place, you have that function that calls all the init_callbacks - having a 
> function of MAX_TYPES lines longer is much better than one of MAX_TYPES * 
> MAX_CALLBACK_METHODS lines long.
>   
Yes, that makes sense and was my original plan to use such init
functions. Good idea with how everything except the init could be
static, that is a nice bonus I didn't think of.
> <snip>
>
>   Other thoughts:
> It may be better working on getting all of this infrastructure/callback methods 
> in place, and implementing one type of object using them instead of focusing on 
> the specific callback method (the web page mentioned doing all the apply stuff). 
>   Why?  That way, if someone does write code for a new object type, all the 
> pieces are in place so they can use the new method.  If only the apply callback 
> is implemented, they can use that logic, but are left using old coding method 
> for the other areas, that then needs to be converted down the road.
>
>   Also, by doing all the different callback methods, it provides better coverage 
> of the callback logic, eg, if there are issues with any of the methods, they 
> will be found sooner vs later.
>   
Well, my original thinking, was that if I were to do it by completing an
object type, instead of a callback type, then it would be somewhat of a
pain to make it redirect to legacy methods for other object types not
yet implemented in the new system. What's your view on that issue?

> Second, if we're going to be writing all new functions, we should use some other 
> 'best practices'.  In particular, for anything that would return a string value, 
> they should be modified so that a string pointer (and length of that pointer) is 
> passed in, instead of using static return buffers.  This will assist if we ever 
> thread the server, but it will also help prevent a few bugs (related to this, 
> sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, 
> and strncpy instead)
Well, I wouldn't say necessarily writing all new functions: I believe
some existing functions can be tweaked fairly easily to fit into the new
system. However I believe that when moving functions that map well over,
we should hand review them anyways, and perhaps use a checklist of
things such as those issues you mention like avoiding static buffer returns.

Alex Schultz