[Freeciv-Dev] Re: [Patch] unit_flag

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Sep 12, 2001 at 07:20:58PM -0400, Ross W. Wetmore wrote:
> This doesn't appear to make much sense.
> 
> First you take out a generic existing function, then you replace it
> with one of limited specific specific utility, then you put back the
> generic function with a different name.
> 
> Create a new name for the new function at least and don't modify any
> more code than is necessary to implement this.
> 
> But I still think you are making unnecessary changes in this case to 
> something that will be removed (or certainly should be) when you do
> the real change that you for some reason don't want to commit to yet.
> 
> This whole effort is looking like a major waste of not only your time
> but everyone else's that needs to resync to these changes, and then
> resync again when they are removed.

The goals are:
 - can switch to pointers in "struct unit"
 - unittype.[ch] methods accept "struct unit_type *"

Nice things:
 - bring a consistent naming schema to unittype.[ch]

The end situation would be methods such as:
  int unit_type_value(struct unit_type *punit_type);

These methods can be called like
"unit_type_value(unit_type(punit))". If such a construct is common I
would create a new method "unit_value" which takes (as the name
suggests) a (struct) unit. Such new methods make also the
"unit_type_*" less called and so more easily changable in the
s/Unit_Type_id id/struct unit_type */ switch over. The "unit_*" would
be touched anymore.

IMHO we have now enough code and knowledge to isolate common
constructs. We should do so if it is reasonable.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner