Difference between revisions of "Token Change Proposals for 5.15 Alpha"
 (→Definitions)  | 
				Tom Parker (talk | contribs)   | 
				||
| Line 29: | Line 29: | ||
{| style="width:100%" border="1"  | {| style="width:100%" border="1"  | ||
! '''Token LST File''' !! '''Token Name''' !! '''Current Syntax''' !! '''Syntax Change''' !! '''Future Syntax''' !! '''Reason''' !! '''Justification for Change''' !! '''Discussion/Approval/FREQ'''  | ! '''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 || 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 || 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 || 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'''  | | 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)  | 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)  | ||
Latest revision as of 14:21, 23 March 2009
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)