[Freeciv-Dev] Re: [RFC] Move cost map interface

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 12:25 PM 02/04/13 +0200, Raimar Falke wrote:
>On Fri, Apr 12, 2002 at 03:39:55PM -0400, Ross W. Wetmore wrote:
>> At 01:56 PM 02/04/12 +0100, Gregory Berkolaiko wrote:
>> >On Thu, 11 Apr 2002, Ross W. Wetmore wrote:

>> There are two parts to switch cases. 
>> 
>> 1)  call the *right* costfn() - I really think this should be pushed
>>     back into a wrapped costfn which allows full program control and
>>     clean interface separation.
>
>> 2)  termination conditions - this is the real point at which code
>>     becomes diverse and you want inline control. I suppose this could
>>     be checkfn() like the costfn(), but somehow I like to see the
>>     actual code at this point from a readability/debugging aspect.
>>     If you add this as a checkfn(), then *any* warmap loop devolves to
>>     the single 3 line for, I think - total black magic to call though.
>
>If you don't do inlining then it doesn't matter if loop in a pf_
>function and call back to test for the exit or loop in the user
>function and call one per turn the pf_get_next function. In both cases
>you have a function call.

You misinterpreted the word inlining. It does not refer to the technical
compiler mode for (mis)handling certain functions, but to having the 
termination code right there inline, and not off in some other buried file. 
One specifically does not want functions here, but programmer readable
code. The switch is just a template construct that the coder should be
able to fill in and clearly see/understand the local application specific 
details.

The mistakes you are making in trying to codify generically diverse and
complex things like step/termination conditions in your model should tell
you something about the alternative of leaving some things to the enduser,
or doing a framework plus a number of simpler well defined cases with a 
user extension hook rather than a monolithic rigidly controlled solution.

The warmap model should lead you in the direction of making a single 
decision during initialization to parameterize the subsequent iterative
loop computation. You most certainly do not want to make all these 
identical choices over and over again on each step, such as by having a
single smorgasborg iterator function in the innermost loop. 

You are also *not* programming for adaptable user code, but rather 
forcing the user to live within the limited variety of choices you 
think to provide.

Inline functions are another concept altogether and the fact that they are
the worst of all possible programming models notwithstanding, does not
change the fact that they are really irrelevant to the discussion here.

>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "We've all heard that a million monkeys banging on a million typewriters
>  will eventually reproduce the entire works of Shakespeare.
>  Now, thanks to the Internet, we know this is not true."

Cheers,
RossW
=====