[Freeciv-Dev] Re: (PR#8959) remove CAR_DIR_D[XY]

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

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8959 >


Jason Short wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8959 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8959 >
>>
>>Found another way to iterate over the world to retrieve a subset of
>>information I see. You really do love this anti-pattern or have a
>>strong desire to write poor code into Freeciv.
> 
> For some subset of "the world", yes.

Mountains are leveled a rock at a time ...

>>But if you just coded in the efficient iterator core from any of the
>>corecleanups, you could change one value to loop over every second
>>element of the rotationally ordered adjacent array to get the cartesian
>>iterators - or just copy the existing code.
> 
> No, that iterator form won't work since it doesn't allow us to change 
> which directions are cardinal.

Clearly a false and foolish statement ... almost any programmer could
work this one out at a moment's need.

> In a hex-tile topology every direction (all six) should be considered 
> cardinal.  Actually "cardinal" is a bit of a misnomer.  Cardinal 
> directions means NSEW directions, but this isn't helpful since we don't 
> know if they are map, GUI, or natural directions.

Just to give you a hint, this has nothing to do with the mechanics of
the core iterator or any efficient implementation model. It has everything
to do with how you organize the data you feed it. Writing oneoff code for
every case you can think of is one inefficient way to handle the runtime
problem, but using a little brain-power to organize the results into a
data-store cache that common code runs, is more elegant, robust and
efficient in the long run.

> All of the users use it to mean "a direction in which we share a border 
> with the tile, rather than just a corner intersection".  For instance 
> rivers only flow in "cardinal" directions; irrigation can only be run in 
> "cardinal" directions, etc.

Yes, yes, yes, ... but this doesn't have much to do with why you have to
implement poor coding practices every chance you see this anti-pattern
scenario to exploit.

It would be so nice to see you work half as hard at working on good
programming practices as you do at trying to justify the bad.

>>Doubling the iteration time for cartesian loops is clearly not a great
>>thing. And has been said, if you keep doubling execution times every
>>code spot you find, your program will soon run twice as slow. Hey, is
>>that not already the case?
> 
> It is a tradeoff against having three times as much code.

I think you increased the number of code lines in a Cartesian loop, but
increasing code lines in these cases has never been one of your concerns
to date. Please don't use such transparently feeble justifications. Let's
try to build good code without being foolish about it.

> jason

But clearly, reducing the code even further by running one efficient and
robust core iterator for virtually all loops with the runtime execution
logic folded into a data lookup at a small fraction of the many different
and thus maintenance unfriendly runtime forms you have created in many
different areas of the code meaning far more lines in total is not.

Your logic is clearly not very logical ... perhaps you could really lay
aside your current mental prejudice and look at this with a fresh mind.

Cheers,
RossW
=====