SL23W41: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 14: | Line 14: | ||
*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''' | |||
** | |||
* | * |
Revision as of 19:19, 13 October 2023
- 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