SL23W41: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
<br /> | <br /> | ||
* '''Change Transaction Type to be a enum if possible''' <br /> | |||
*Conversion of FakeKey, VariantId etc. to sealed classes | *Conversion of FakeKey, VariantId etc. to sealed classes | ||
Line 14: | Line 16: | ||
*Refactor of Flambda<?,?> generic to only use Flambda<?> as the second generic was unused in 99% of cases | *Refactor of Flambda<?,?> generic to only use Flambda<?> as the second generic was unused in 99% of cases | ||
*'''Cleanup OptionActions as nearly all systems now should support changeOptionByDraft combined with passing a sealed KDraft impl''' | *'''Cleanup OptionActions as nearly all systems now should support changeOptionByDraft combined with passing a sealed KDraft impl''' | ||
*'''Fakes need to be identified with UUIDs in the future''' | |||
**'''We can justify that because in nearly all cases a player will be changing only data at a local place''' | |||
**'''So reusing names like "front, back, top, bottom" is more important than not having duplicated names of objects''' | |||
** | |||
* | * |
Latest revision as of 14:02, 15 October 2023
- Change Transaction Type to be a enum if possible
- Conversion of FakeKey, VariantId etc. to sealed classes
- Definition of globally used Keys for all components using OptionCaches
- Allows usage of Key+OptionDraft combination to change any value
- Planning for more Key implementations
- QueryParams / For a QueryBuilder kind of page
- WorldKey
- LandKey
- Boc / ChunkliKey / Changing Blueprints (Tagging, Rating etc?)
- Possibly generaliyed UserPodKey to support all Pod types at once similar to VariantId keys?
- Refactor of Flambda<?,?> generic to only use Flambda<?> as the second generic was unused in 99% of cases
- Cleanup OptionActions as nearly all systems now should support changeOptionByDraft combined with passing a sealed KDraft impl
- Fakes need to be identified with UUIDs in the future
- We can justify that because in nearly all cases a player will be changing only data at a local place
- So reusing names like "front, back, top, bottom" is more important than not having duplicated names of objects