[Freeciv-Dev] Re: (PR#6257) recodify map_pos<->index conversion to use native positions

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

Bzzzt  ... remember recent history, don't relive it :-).

Jason Short wrote:
> Gregory Berkolaiko wrote:
> 
>>On Tue, 23 Sep 2003, Jason Short wrote:
[...]
>>How about introducing 2 new macros
>>      map_to_native_x
>>      map_to_native_y
> 
> Clever.  This is generally the type of thing we want to avoid - since 
> most of the time it will only lead to misuse - but here it is helpful.

Actually, very stupid. map_adjust_x() and map_adjust_y() memories should
hopefully rekindle the endless hassles of assuming that the two coordinates
are independent. The transformation of a gen-topology 2-D coordinate pair
cannot assume independence as the first extension case below shows.

The equivalence operation applies only to the current standard to native
mappings, and will be very shortlived - so short that hopefully the clever
stupidity of it will not have time to sink in :-).

> Patch attached.
> 
> Note that for for iso-maps the calculation will be something like
> 
>    y: (map_x + map_y - map.xsize)
>    x: (map_x - map_y + map.xsize - (map_x + map_y - map.xsize) & 1) / 2
> 
> which is why both map x and y values are needed for the macros (which is 
> why taking them individually is generally a bad idea).

Yup, so don't even go near the above solution.

> I used map_pos_to_native_[xy] for the names - along the lines of 
> map_pos_to_index.  Making them longer discourages people from using them 
> needlessly :-).
> 
> jason
> ------------------------------------------------------------------------

There are two quick solutions to the above.

1) pass in the required working storage variables as arguments. The
    disadvantage is the exposing of internal implementation through the
    interface and the aggravation caused by making the programmer do this
    everytime.

2) define static globals that are defined and well documented as being used
    for this purpose. The disadvantage here is one of type safety, and if the
    same working storage is used in nested macros, overwriting values.

Neither of these come close to the disadvantages of the clever solution.

Cheers,
RossW
=====