Token Change Proposals for 5.15 Alpha

From PCGen Wiki
Revision as of 14:21, 23 March 2009 by Tom Parker (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Underlying Philosophies for Changes

  1. Elimination of magical values: Values like -1 that represent unlimited should be replaced by "UNLIMITED" or a String otherwise explictly identifying the meaning of the special value.
  2. Elimination of duplicate code by consolidating tokens
  3. Completion of Ability Object changes
  4. Preparation for CDOM parsing of tokens
  5. Performance (in one or two cases)
  6. Elimination of complicated, undocumented interactions

Definition of "Reason" Terminology

  • Syntax: This is a proposed syntax change to improve clarity and eliminate a magical value that is not clearly identified
  • Consistency: This is a proposed change to improve consistency between tokens
  • Duplicate: This is a proposed change to eliminate an alternate way of achieving an identical result
  • Upgrade: This is a proposed change based on upgrades made to PCGen to keep the application consistent
  • Nonfunctioning: This is a proposed change due to the token not functioning in the current rev of PCGen
  • Unnecessary: This is a token that provides insights, but requires no processing by the code
  • Performance: This is a proposed change that will reducing parsing complexity and thus improve speed
  • Complicated: This is a proposed change that eliminates complicated behavior

Proposed Token Changes

There is a complete rebuild of CHOOSE proposed: CHOOSE Proposal for 6.0

Token LST File Token Name Current Syntax Syntax Change Future Syntax Reason Justification for Change Discussion/Approval/FREQ
Class HASSUBCLASS HASSUBCLASS REQUIRE :YES HASSUBCLASS:YES Consistency Tokens are A:B, not A IMPLEMENTED
Class HASSUBSTITUTIONLEVEL HASSUBSTITUTIONLEVEL REQUIRE :YES HASSUBSTUTIONLEVEL:YES Consistency Tokens are A:B not A IMPLEMENTED
Class HASSPELLFORMULA HASSPELLFORMULA Deprecate none Unnecessary This is for intelligence gathering/debugging value to the data team, unneeded by code IMPLEMENTED
Class CHECK* CHECK* Deprecate none Unnecessary Unused code IMPLEMENTED

In addition, it would be nice to define for the 6.0 branch the preferred output format of SOURCEDATE: ... once it is actually stored as a DATE, I doubt we want it written out in the default form (e.g. Wed Mar 28 00:00:00 EDT 2007)