[Crossfire-wiki] [Crossfire DokuWiki] page changed: user:rednaxela: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:35

User        : rednaxela

Edit Summary: 



@@ -1,53 +1,3 @@

- **This page is a draft document in my user namespace. Will move to the d
ev_todo namespace when the draft is ready for public review**

+ **This page was a draft document in my user namespace. It has since move
d to the dev_todo namespace**

  

- ----

- 

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

- ===== Reason =====

- 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

-   * 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 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 *);

-     ...

- } 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.

-   * 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.

- 

- ===== 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
 chunks as possible while keeping the SVN code working is preferable.

-   * Try to give a bit of notice before commiting refactoring changes, no
ting specifically what refactoring changes you intend to commit.

-   * Document what you refactor, when you refactor it, and it's form in t
he 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 th
ere.

-     * Adding to a wiki table listing new, removed, or moved functions re
sulting from the refactoring.

- ==== Later ====

-   * Clean up the refactoring.

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

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

- ==== Eventually... ====

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

- 

- ===== More information =====

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

+ See: [[dev_todo:refactor|dev_todo:refactor]]





IP-Address  : 66.222.158.169

Old Revision: http://wiki.metalforge.net/doku.php/user:rednaxela:refactor?
rev=1160411570

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



-- 

This mail was generated by DokuWiki at

http://wiki.metalforge.net/