Difference between revisions of "Token Change Proposals for 5.15 Alpha"
(→The following are the actual proposed changes to tokens:) |
Tom Parker (talk | contribs) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 3: | Line 3: | ||
|} | |} | ||
| − | == | + | ==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 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. | ||
| Line 12: | Line 12: | ||
# Elimination of complicated, undocumented interactions | # 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 | * Syntax: This is a proposed syntax change to improve clarity and eliminate a magical value that is not clearly identified | ||
| Line 23: | Line 23: | ||
* Complicated: This is a proposed change that eliminates complicated behavior | * Complicated: This is a proposed change that eliminates complicated behavior | ||
| − | == | + | ==Proposed Token Changes== |
There is a complete rebuild of CHOOSE proposed: [[CHOOSE Token Proposal for 6.0|CHOOSE Proposal for 6.0]] | There is a complete rebuild of CHOOSE proposed: [[CHOOSE Token Proposal for 6.0|CHOOSE Proposal for 6.0]] | ||
| 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)
