Re: ABILITY Output Token - Several member variables that we don't need?
- Hi Tom,
> > * The class itself doesn't use them<snip OS code>
> Now looking at the code, AbilityToken does use them as I expected;
> I'm not sure you're following my description of how they are used.
> They are a cache. You have to consider that this code is massively
> re-entrant based on how it is used in the output sheets.
> Consider the impact of this Java code:
> AbilityToken at = new AbilityToken();
> for (int i = 0; i < 10; i++)
> System.out.println(at.getToken("ABILITY.Special Ability." + i + ".NAME", pc, eh));
> This enters the getToken method 10 times.
> In effect, this is what happens with actual OS code like this:
> Note the %specialAttack is just like the "i" in my Java loopAh, now I get it, I was lost on the OS causing the re-entrant thing. OK, so I've modified it to be a local check which goes back to a boolean called cacheAbilityProcessingData.
> above... it increments inside of the FOR loop in the output sheet
> rather than a direct "for" loop in Java.
> Note what happens inside of AbilityToken for these loop cases:
> The first time through getToken, it passes to getTokenForCategory,
> and the "cache" (composed of cachedPC, lastCategory, cachedPcSerial
> and lastToken) is all null/empty. getAbilityList is called since
> the cachedPC != pc test is true.
> The second time through getToken, it passes to getTokenForCategory,
> but (1) the PC is the same (2) the Category is the same (3) the PC
> serial is the same and (4) the "lastToken" is the same (since the
> lastToken is actually the first item in the output token, which in
> this case is "ABILITY")
> As a result of the cache test "passing" (meaning all false and the
> IF is not entered), getAbilityList is not called the second (and i-
> th where i > 0) time through the loop. This is a performance
> enhancement for output.
> We could debate whether it's valuable in this instance, but I don'tCompletely Agree :)
> think we should be worried right now about this level of detail and
> code cleanup in the output tokens. I would prefer a focus on
> behavior vs. docs. In this case in particular, I'm not worried,
> since the Ability list will be maintained (and cached) by the
> AbilityFacet, so the output token will not have to do this type of
> caching in the future (which will help clarity in the output tokens)