Summary: Emphasize OOP for path finding code
                 Project: Freeciv
            Submitted by: pepeto
            Submitted on: Wednesday 06/24/2009 at 10:49
                Category: general
                Severity: 2 - Minor
                Priority: 5 - Normal
                  Status: None
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None



Since pf_map use OOP polymorphism, it seems clearer to emphasize the OOP
style with renaming the pf public interface with pf_map_* prefix.

The attached path (for trunk) renames:

pf_map functions:
pf_create_map -> pf_map_new
pf_destroy_map -> pf_map_destroy
pf_get_path -> pf_map_get_path
pf_get_positition -> pf_map_get_position
pf_next -> pf_map_iterate
pf_get_parameter -> pf_map_get_parameter

related to the map iterator functions:
[new function] -> pf_map_iterator_get_tile
pf_next_get_path -> pf_map_iterator_get_path
pf_next_get_position -> pf_map_iterator_get_position

pf_path functions:
pf_print_path(log_level, path) -> pf_path_print(path, log_level)
pf_destroy_path -> pf_path_destroy
pf_last_position pf_path_get_last_position

pf_iterator -> pf_map_iterate_tiles
pf_iterator -> pf_map_iterate_positions
pf_iterator -> pf_map_iterate_pathes
Those many macros allows to iterate only one kind of informations, because
sometimes, we don't need full infos for a position. Also, all those macros
take a condition as third argument to determine if the start_tile should be
iterated too (minor cases).

variables names:
map -> pfm
pf_map pointers where often named map which is not so great since map is also
the name of the static civ_map structure.

Also, I noticed one missing pf_path_destroy in client's send_goto_tile().


File Attachments:

Date: Wednesday 06/24/2009 at 10:49  Name: pf.diff.gz  Size: 13kB   By:



Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to