Skip to content

Introduce CompositeValue - #2616

Draft
aromaa wants to merge 3 commits into
api-18from
feature/composite-value
Draft

aromaa wants to merge 3 commits into
api-18from
feature/composite-value

Conversation

@aromaa

@aromaa aromaa commented Sep 20, 2026

Copy link
Copy Markdown
Member

A CompositeValue<K, E> consist a collection of key value pairs that are merged in to single a value. A single key value pair can be offer or removed from a DataProvider.

A new ValueLike<E> is introduced to separate the concept of Value<E> which only truly holds a single value at given time. The new CompositeValue<K, E> only inherits from ValueLike<E> and existing overloads working with values won't accept composite values and they have their own overloads. This prevents users from erroneously constructing values that are not valid.

TODO:

  • Empty CompositeValue#Parent is currently valid, should this be disallowed?
    • What's the contract of removing the last value from it?
    • We need to return some valid E. This contract is served by ElementMergeFunction#Defaulted for now.
    • Change ValueLike#get to @Nullable? Can override in Value<T>.
      • Change ValueLike#get to Optional<E>? Can't override, a lot of churn for the user?
  • Abstract delete operations under a single "key" interface?
    • DataProvider#Composite serves this purpose currently. Offer and get works through ValueLike<E>.
  • Better name for ElementMergeFunction?

@Zidane

Zidane commented Sep 20, 2026

Copy link
Copy Markdown
Member

@aromaa

What values in Vanilla will be composites? Is the intention here to represent the true data composition of the game? We expose several keys that are part of a composite in the backend but the composite isn't shown.

Unless I misunderstand the intention here?

@aromaa

aromaa commented Sep 20, 2026

Copy link
Copy Markdown
Member Author

The primary motive is vanish. So the key would be CompositeValue<PluginContainer, VanishState> where multiple plugins can offer / remove their own VanishState freely without conflicts. This means the player stays vanished as long as at least one plugin has requested it and they will only become visible after all of the plugins have removed it.

While the current state works kinda okay-ish because its a global on / off toggle, it becomes more complicated with contextual data where the state can be toggled per player per viewer. I view this as one of the prerequisites for contextual data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants