[Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet

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

Jason Short wrote:
> rwetmore@xxxxxxxxxxxx wrote:
> 
>>Jason Short wrote:
>>
>>>[rwetmore@xxxxxxxxxxxx - Tue Jul 29 03:04:06 2003]:
[...]
>>And please quit making these false or (self-)contradictory statements :-).
[...]
> To rely on the client to separate the special case from all the other 
> real-but-not-normal cases discards all ability for debugging. 

I don't know how you can say this with a straight face ...

> If the 
> client actually does send any real-but-not-normal coordinates then you 
> are guaranteed to have a bug (since (-1,-1) is also 
> real-but-not-normal), 

No, Jason, it is "special", not "real-but-not-normal". Your definition is
not the useful one since in fact (-1,-1) is already special and imbedded
in the codebase in many places as being special.

Use the existing definition, at least until the discussion on how to get
rid of (-1,-1) and replace it with a non-coordinate flag is finished. That
I am afraid will not happen though, since (-1,-1) as a special case is by
far the best solution with the topologuy code being taught this right from
the get go, and hopefully expanding on this to make it clear how to deal
with this problem in general.

 > and guaranteed to not be able to find it (since it
> will be treated as the special case and will generate no obvious error).

You need to rethink how to do gen-topologies in this area. Please step back
and do so for a moment and it will hopefully become clearer then.

> This is the argument which I have seen no satisfactory answer for.  Yet 
> obviously you think you have answered it, so we are at an impasse, again.

Choice of definition ... which condition takes precedence, the one that
works from now on or the one that hides problems for today. Religion always
seeks to hide its problems and technical merit tends to work. Think, man ...

> Your counter-argument is that it is bad to force the client to have the 
> same definition of "normal" as the server.  I agree in principle, but I 
> don't see that this outweighs the argument above. 

I'm losing you here. Normal can be arbitrarily defined in any module for any
purpose one sees fit. If the client and server share in a conceptual module,
they need to share its rules for local normal definition. This is true for
encapsulated modules withing the client and server as well. Outside of the
properly interfaced module boundaries no sharing is required. Standard OO...

But this does not translate into a reason to force everyone to have one
definition of normal - one should be free to choose the one needed for a
particular task within the task module boundaries. In this case, do not
split the module acrosss the client and server by sharing "normal rules",
but deal only with real/unreal which are hard conditions that don't have
this problem.

 > And since client and
> server must already agree that (-1,-1) is not normal this argument is 
> lessened.

They should not care whether it is normal or not, just whether it is a
real/unreal coordinate, and (-1,-1) is unambiguously defined to be special
aka unreal in generic code.

> jason

Cheers,
RossW
=====