Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: unit flags/capabilities

[Freeciv-Dev] Re: unit flags/capabilities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Sutton <ansutton@xxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: unit flags/capabilities
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 29 Nov 2001 16:17:31 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Thu, Nov 29, 2001 at 09:47:29AM -0500, Andrew Sutton wrote:
> > > 2. it isn't very extensible
> >
> > You first have to state in which direction and why you want to
> > extend. What is the goal? What is the interface you want to achive?
> the interface isn't the goal. its the creation of a gracefully extensible 
> capability description for all units. the entire purpose is to tie all this 
> information into a single uniform resource.

So you propose to extend the current implementation to achieve a
larger flexibility. However this extension doesn't provide an
immediate benefit and there is also no project/patch/feature that I
know which would benefit. Lastly you can argue that it is a cleanup
but a cleanup leaves the interfaces unchanged. And IMHO the flag and
role code/handling doesn't need a cleanup.

> > > 3. it groups widely different types of data together into one bitfield.
> >
> > Data which are all flags (booleans) and may be used independently. You
> > can have a unit which have the F_SPY,F_MARINES,F_IGTIRED flags. A
> > bitfield is a quite good implementation.
> yes. and it still is a bitfield implementation :) except now, there's alot 
> more bit space to choose from.

What you want to put there.

> > > 4. it separates out data that should be there.
> things like diplomacy actions, settler actions. these are all capabilities 
> that can be brought under the auspices of a single flags settings. uniformity 
> is the goal.
> > We both know that such a way would require a major
> > rewrite. Fortunately freeciv doesn't have this many types and would is
> > doesn't require a big flexibility because the set of types is more or
> > less constant. I agree that from a programmers point of view it may be
> > nicer to have a finer grained type set like struct land_unit, struct
> > water_unit and struct air_unit.
> that might be a good initial derivation. i can't think of any reason why you 
> wouldn't do that.

Because it is a lot of work with no user visible benefit. And from a
programmers point of view it is unnecessary (for this large amount of

> >   struct {
> >     int fuel;
> >   } air_unit;
> >   struct {
> >     enum unit_activity activity;
> >     int activity_count;
> >     int activity_target;
> >     int connecting;
> >   } settler;
> that's just grouping parameters. it doesn't really achieve the desired 
> inheritence effect

I know.

> - although it does explicitly separate out the information.

Which is a good thing.


 email: rf13@xxxxxxxxxxxxxxxxx
  The Software is not designed or licensed for use in on-line control
  equipment in hazardous environments, such as operation of nuclear
  facilities, aircraft navigation or control, or direct life support
    -- Java Compiler Compiler Download and License Agreement

[Prev in Thread] Current Thread [Next in Thread]