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

[Freeciv-Dev] Re: unit flags/capabilities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: unit flags/capabilities
From: Andrew Sutton <ansutton@xxxxxxx>
Date: Thu, 29 Nov 2001 10:28:30 -0500

On Thursday 29 November 2001 10:17 am, you wrote:
> 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.

possibly not, but you can never underestimate the future needs of the 
program. why pass up a chance to have something be extensible - especially if 
it can coexist with the current model. you're right. it doesn't replace 
anything. that code works fine. as developers find the need for greater 
flexibility in unit capability specification and testing, they can roll 
existing code to this framework. when all the code has been rolled over, the 
older unit_type framework can be extricated from the source completely.

> What you want to put there.

everything that a unit can "subscribe" to. basically any set of flags that 
could possibly be defined for any unit.

> 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
> cost).

it's likely that it could be written to coexist with the current model. 
rember, everything's based on the unit struct and the unit struct is passed 
around as a ptr. legacy code can use the existing framework. newer code that 
prefers an inheritance model can perform the necessary casting operations.

> > 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.

yes :) i might add something like that to the unit_type for values to certain 
flag sets (e.g. transport capacity) - it would also coexist until the legacy 
code has been replaced.

andy


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