Token Change Proposals for 5.15 Alpha
Revision as of 14:21, 23 March 2009 by Tom Parker (talk | contribs)
Underlying Philosophies for Changes
- 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.
- Elimination of duplicate code by consolidating tokens
- Completion of Ability Object changes
- Preparation for CDOM parsing of tokens
- Performance (in one or two cases)
- 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)
