[Crossfire-wiki] [Crossfire DokuWiki] page changed: 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/29 00:55

User        : rednaxela

Edit Summary: Small revisions based on IRC chat



@@ -3,26 +3,25 @@

  Currently in the crossfire code, how objects behave is intertwined all t
hroughout the code, and this is in many ways a problem as it makes it diff
icult to find code related to a type of object. It's current state also ma
kes it relatively difficult to add code for new object types. Though it wi
ll never be that easy to add object types, refactoring could improve this 
significantly. Also, refactoring this to separate code for different objec
t types, will make it easier to find current overloading of object attribu
tes, 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
 itself:

-     * By object

-     * By archetype

-     * By type number

+   * Allow operations such as 'apply' to be specified in pointers per obj
ect type number, however only the last being used in the refactoring

    * Separate object type specific code into separate files.

+   * Make sure it is easy to a later stage implement per-object and per-a
rchetype hooks.

  

  ==== Implementation Details ====

  === Code organization ===

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

    * Code used by multiple distinct types, but is not generic to all obje
ct 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
 as different types of armor, where all behave the same but have different
 type numbers. Just make sure it is logical.

  === Function pointers ===

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

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

-     int (*drop)(object *);

+     int (*apply)(object *ob, object *pl);

+     int (*drop)(object *ob);

      ...

- } ob_methods;</code>For per-object hooks, objects would have a struct me
mber added as "//ob_methods *methods;//" (accessed as "//ob->methods//"). 
Per-arch hooks would be done as a similar struct member added to the arche
type struct. In those cases, the "methods" pointer will be NULL unless the
re are methods in it. For per-type hooks, they would be stored in an array
 of "ob_methods type_methods[MAXTYPE];". Function pointers will be NULL if
 unset.

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

+ } ob_methods;</code>For per-type hooks, they would be stored in an array
 of "ob_methods type_methods[MAXTYPE];". Function pointers will be NULL if
 unset.

+ For per-object hooks if/when implemented, objects would have a struct me
mber added as "//ob_methods *methods;//" (accessed as "//ob->methods//"). 
Per-arch hooks if/when implemented would be done as a similar struct membe
r added to the archetype struct. In those cases, the "methods" pointer wil
l be NULL unless there are methods in it.

+   * One would not access function pointers directly, instead one would u
se functions to add hooks, and functions in the convention of "ob_apply()"
 and "ob_drop()" to run them.

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

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

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

  





IP-Address  : 66.222.158.169

Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:refactor?rev=
1162054825

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



-- 

This mail was generated by DokuWiki at

http://wiki.metalforge.net/