Skip to content

CounterListType: add List for easy extending counters#10213

Draft
Hanmac wants to merge 4 commits intomasterfrom
counterListType
Draft

CounterListType: add List for easy extending counters#10213
Hanmac wants to merge 4 commits intomasterfrom
counterListType

Conversation

@Hanmac
Copy link
Copy Markdown
Contributor

@Hanmac Hanmac commented Mar 29, 2026

Part of #10076

adds an easy extendable List for Counters where colors can be defined

@Hanmac
Copy link
Copy Markdown
Contributor Author

Hanmac commented Apr 1, 2026

Might be interesting if we can add some Icons for such List Counters too

like MTGO has Icons for these: https://mtg.wiki/page/Page_counter

@Hanmac
Copy link
Copy Markdown
Contributor Author

Hanmac commented Apr 18, 2026

@tool4ever most of the remaining enum types are used for AI in isNegativeCounter and isUselessCounter

i might try to move them into another text files too, or what's your opinion?

@tool4ever
Copy link
Copy Markdown
Contributor

hmn, binding them to Enum to enforce the correct types at compile time has some advantages like not having to worry about String typos or them drifting apart 🤔

I'm not sure giving that up would be worth it?

@@ -16,12 +16,17 @@ static CounterType getType(String name) {
try {
return CounterEnumType.getType(name);
} catch (final IllegalArgumentException ex) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hate this control flow by exception handling anti-pattern:
we should really try to get rid of it instead of relying even more on it

Copy link
Copy Markdown
Contributor Author

@Hanmac Hanmac Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Hanmac
Copy link
Copy Markdown
Contributor Author

Hanmac commented Apr 20, 2026

hmn, binding them to Enum to enforce the correct types at compile time has some advantages like not having to worry about String typos or them drifting apart 🤔

I'm not sure giving that up would be worth it?

Typos already happens anyway, they are just treated as CounterKeywordType which is the fallback anyway

also, we can't really support custom-types without allowing typos

@Hanmac Hanmac mentioned this pull request Apr 20, 2026
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants