[Crossfire-wiki] [Crossfire DokuWiki] page added: dev_todo:refactor

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:



Date        : 2006/10/09 11:33

User        : rednaxela

Edit Summary: created from user:rednaxela:refactor



====== Object-type refactoring ======

===== Reason =====

Currently in the crossfire code, how objects behave is intertwined all thr
oughout the code, and this is in many ways a problem as it makes it diffic
ult to find code related to a type of object. It's current state also make
s it relatively difficult to add code for new object types. Though it will
 never be that easy to add object types, refactoring could improve this si
gnificantly. Also, refactoring this to separate code for different object 
types, will make it easier to find current overloading of object attribute
s, making it easier to eventually refactor the overloading out.



===== Proposal =====

==== General Idea ====

  * Allow operations such as 'apply' to be specified in pointers in all of
 the following ways, however only the last being used in the refactoring i
tself:

    * By object

    * By archetype

    * By type number

  * Separate object type specific code into separate files.



==== Implementation Details ====

=== Code organization ===

  * Use form of server/types/foo.c or server/types/foo/bar.c depending on 
if the object type requires multiple C files to be clean.

  * Code used by multiple distinct types, but is not generic to all object
 types should be put in server/types/common/ with a logical filename.

  * Doesn't necessarily mean one type number per file, due to cases such a
s different types of armor, where all behave the same but have different t
ype numbers. Just make sure it is logical.

=== Function pointers ===

  * Function pointers to the 'object methods' will be stored in a struct i
n a form like:<code>typedef struct ob_methods {

    int (*apply)(object *, object *);

    int (*drop)(object *);

    ...

} ob_methods;</code>For per-object hooks, objects would have a struct memb
er added as "//ob_methods *methods;//" (accessed as "//ob->methods//"). Pe
r-arch hooks would be done as a similar struct member added to the archety
pe struct. In those cases, the "methods" pointer will be NULL unless there
 are methods in it. For per-type hooks, they would be stored in an array o
f "ob_methods type_methods[MAXTYPE];". Function pointers will be NULL if u
nset.

  * One would not access function pointers directly, instead one would use
 functions to add hooks, and a "cf_method()" function to run them.

  * Each file would register whatever hooks it wanted in an init function 
for that specific file.

    * Will have to put an "init_types()" function in the main code, contai
ning calls to all type_specific init functions.

  * Will take some forethought to make sure that one provides good enough 
callback parameters for all uses of a hook.



===== Plan =====

==== To start ====

  * Begin refactoring some things to the new system.

  * Start with simple things such as moving the apply code for all types.

  * Convert things to function pointers as needed.

  * Aim for ~90% of type-specific code moved into the new system.

==== Policy ====

  * Commit refactoring changes frequently in very small chunks. As small c
hunks as possible while keeping the SVN code working is preferable.

  * Try to give a bit of notice before commiting refactoring changes, noti
ng specifically what refactoring changes you intend to commit.

  * Document what you refactor, when you refactor it, and it's form in the
 system. Documentation including:

    * In addition to updating the ChangeLog, make a more detailed entry in
 server/types/ChangeLog, in the format and with the details specified ther
e.

    * Adding to a wiki table listing new, removed, or moved functions resu
lting from the refactoring.

==== Later ====

  * Clean up the refactoring.

  * Attempt to get the remaining type-specific code moved into the system.

  * Collapse some groups of types - there are a bunch of different armor t
ypes, but for logical purposes, they are the same, just go on different bo
dy parts.

==== Eventually... ====

  * Implement some sort of [[dev_todo:unified_event_system|unified event s
ystem]] and integrate with this object-type separation. Not a priority rig
ht now, but something to keep in mind for later.



===== More information =====

  * [[http://thread.gmane.org/gmane.games.crossfire.general/1928|Crossfire
 mailing list: Code restructuring]]



IP-Address  : 66.222.158.169

Old Revision: none

New Revision: http://wiki.metalforge.net/doku.php/dev_todo:refactor



-- 

This mail was generated by DokuWiki at

http://wiki.metalforge.net/