Sealed class detection is buggy when parameters are overriden

[sksamuel]

sealed class Sealed
data class One(val a: String) : Sealed()
data class Two(val a: String, val b: Int) : Sealed()

Will always pick the first one.

[sksamuel]

@VapidLinus

[sksamuel]

So delving in deeper, when you override a value, you're not overriding the whole object, but overriding that specific value, which means there's ambiguity over which to pick.

So in your original example:

config.toml

total-miss-count = 12
blank-emote = { id = "139498586236518441", guild = "153217084425764864" }

default-config.toml

total-miss-count = 7
blank-emote = { name = ":black_small_square:" }

Merged result

total-miss-count = 12
blank-emote = { name = ":black_small_square:", id = "139498586236518441", guild = "153217084425764864" }

So now which subtype to pick ?

[sksamuel]

I guess for TOML only, we could introduce a flag that allows you to specify that an inline table completely overrides?

[VapidLinus]

Maybe it could be an annotation on the sealed class that "flags" it for overriding the table completely?

That way it would be backwards compatiable and the old behavior can still be achieved when wanted.

[sksamuel]

That would be nice from a user point of view. The problem is hoplite generates the entire tree of values before then applying it to the config classes.

That idea might work if the node's where lazy which perhaps we could do in the 2.0 update that I'm planning.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sksamuel]

#329