On Tue, 31 Jan 2017 17:14:49 +0100
"Enrico Weigelt, metux IT consult" <[email protected]> wrote:
> Okay, then most uses of Set could be lifted to List (except the few
> cases where specific modifiers need to be removed from the caches),
> correct ?

I can not think of a counterexample.  Indeed I have done this in a few
places in the past.  I counsel small steps and plenty of regression
testing.

> > However FreeCol
> > has a history of surprising its developers with unexpected corner cases.  
> 
> Can you name some, which I should consider ?
> 
> >> Digging a bit further, it really seems the whole duplicity problem
> >> (perhaps even the need for the source attribute)  
> > 
> > Source attributes probably started as a GUI feature.  
> 
> Okay, what exactly are they used for here ?

I can answer both the above questions with reference to the comment in
Colony.getReducePopulationMessage.

More generally, source attributes are used (surprise!) so we can see what
object is providing the feature.  There are a few places where a feature is
needed and we want to find the objects that can provide it.  IIRC the AI
used to be full of hardcoded references to building/unit types, which I
replaced with calls to find type/s with the desired ability. 
 
> Do you know any case where that's also required across several object
> types ? (IOW: need to sort *after* modifier lists from separate sources
> had been cat'ed together, instead of just the source lists.).
> 
> OTOH: what about using TreeSet and giving Modifier the appropriate
> compareTo() method, so they're always sorted automatically ?

AFAICT there are two places where sorting is required, at point of
calculation of the final result, and for display purposes to the player.
Actually, the first probably precedes the second anyway.  Nevertheless,
both uses are terminal uses --- at this point all modifiers have
been collected, and the list is stable and not used further.  Thus
it is actually disadvantageous to spend the effort keeping it sorted
while under construction.

> >> Actually, there won't be any need for recalculation, as there wouldn't
> >> be any need for any caches (outside the operators themselves), which
> >> need to be maintained.  
> > 
> > I do not understand what you are saying here.  AFAICT you were proposing
> > a type of compound modifier.  Many(most?) modifiers can change, at least
> > in the sense of being added and/or removed.   
> 
> Seems I wasn't a bit unclear. My proposal wouldn't change individual
> modifiers anymore (and no modifier propagation). Instead the operators
> would directly call through to the appropriate objects where the
> modifiers originally came from.
> 
> For example, Colony could have a StorageCapacity operator, which
> operates on the Colony's building list, calling their StorageCapacity
> operators.
> (okay, maybe not the best example, as we could implement that explictly
> in Colony::getStorageCapacity()).

This works for easy cases like warehouse storage.  Complex cases with
different priority modifiers will require more messing around.  And I
agree that the Colony/Building modifier caching is awkward.  However the
worst cases (where there is more than a few modifiers) will be in combat
and production, where we *must* be able to collect the entire list of
relevant modifiers because of the display requirements.

> Yeah, but you need to know *exactly* how the modifier propagation
> works - the whole spec is almost its own programming language, which
> makes the whole thing pretty hard to understand and maintain.

Do not rubbish the spec.  You were not around for the hard coded
disorder that reigned before we had it.  The spec was a big step
forward for FreeCol.  The main problem with it is that it is sadly
incomplete.  There are abundant opportunities to promote game data to the
spec.

> Well, the problem with that is that this moves complexity from the
> application to the spec and creates subtle interdependencies.

The dependency should all be one way.  If it is not, then whatever the
spec is depending on needs to move out of the code.

> Perhaps I was a bit unclear: certainly we've got several user visible
> calculation steps, eg. how much defense points certain buildings
> contribute, etc. But these always 1:1 mapped to an specific modifier
> (individual Modifier instance) or instead all the modifiers from certain
> source (eg. specific building) ?

Still unclear this end.

Cheers,
Mike Pope

Attachment: pgp5F38GAjx6u.pgp
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freecol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Reply via email to