Loading ...
Sorry, an error occurred while loading the content.

Re: ABILITY Output Token - Several member variables that we don't need?

Expand Messages
  • karianna03
    Hi Tom, ... ... Ah, 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
    Message 1 of 6 , Sep 8, 2009
    • 0 Attachment
      Hi Tom,

      > > * The class itself doesn't use them
      >
      > 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:

      <snip OS code>

      > Note the %specialAttack is just like the "i" in my Java loop
      > 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.

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

      > We could debate whether it's valuable in this instance, but I don't
      > 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)

      Completely Agree :)

      K
    Your message has been successfully submitted and would be delivered to recipients shortly.