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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Apr 14, 2002 at 12:50:26AM -0400, Ross W. Wetmore wrote:
> 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.

I'm leaving things to the end user. A normal user of my current
proposal will contain like this:

struct pf_parameter parameter;
pf_map_t map;

// fill out parameter
parameter.owner=unit_owner(punit);
....

map=pf_get_map(parameter);

do {
  struct pf_position position;

  if(!pf_get_next_position(map, &position)) {
    // no more positions
    break;
  }

  if(position is interresting) {
    struct pf_path path;

    pf_construct_path(map, &position, &path);
    do something with path
  }
} while(position is not some kind of end position);

> 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
 "Many of my assistants were fans of Tolkien, who wrote 'Lord of the Rings'
  and a number of other children's stories for adults.  The first character
  alphabet that was programmed for my plotter was Elvish rather than Latin."
    -- from SAIs "life as a computer for a quarter of a century"