Skip to content

feat: add enum, size limit and handle types - #16

Merged
NenkaLab merged 1 commit into
masterfrom
feat/type-constraints
Nov 4, 2026
Merged

NenkaLab merged 1 commit into
masterfrom
feat/type-constraints

Conversation

@NenkaLab

@NenkaLab NenkaLab commented Nov 4, 2026

Copy link
Copy Markdown
Member

What changed

Three additions to Type, written in the existing text form so older type strings still read the same:

  • enum<a|b>: a string that is one of the listed values.
  • A size limit after a type: string[..100], int[0..100], list<T>[1..], map<T>[..5], bytes[..1024]. It limits the length of a string, bytes, list or map, or the value of an int or double. Either end may be left out, and it combines with ? and with item types.
  • handle<kind>: a string that names something the host keeps for the plugin, such as a message token.

conform looks through a limit. fits treats the new types as equal-only, like the other non-structural types.

Why

Type.ANY and unbounded strings and lists leave the size of what crosses the boundary to the receiver. Limits and enums let a spec say it, and handle lets the host find token fields from the spec instead of a hard-coded list (a follow-up in MessengerBotR).

Compatibility

The protocol version is still 0, so it is not raised. A peer built before this change cannot read the new type text. Raise the protocol version when the first release ships.

Testing

:contract:test and :tck:test pass, including seven new cases for the text form, malformed text, enums, limits, nested limits, handles and conform. :android:testDebugUnitTest fails here with Unsupported class file major version 70 because of the newer JDK, and fails the same way on an unchanged master.

@NenkaLab
NenkaLab merged commit 1935980 into master Nov 4, 2026
1 check passed
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.

1 participant