Why do

ModifierNodeElement

implementations usually provide their own hashCode and equals implementations? What about using a data class?

they don't need the extra baggage that comes from a data class, so why have it. Also, in libraries, you should avoid data classes altogether

So do the extra generated copy() and componentN() result in a realistically larger generated code size? I would imagine hand-writing hashcodes is also more error prone.

there's an article from JW, let me find it

Internally we do use data classes for modifier nodes occasionally. They should be private classes though so it’s a very easy decision to change later on

well that's a loadful of good arguments from Jake, thanks for the link gratitude thank you

Again,

Modifier.Node

implementations shouldn’t be public

So do the extra generated copy() and componentN() result in a realistically larger generated code size? I would imagine hand-writing hashcodes is also more error prone.

You can generate

hashCode

and

equals

methods https://www.jetbrains.com/help/idea/generating-code.html#generate-equals-hashcode

I'd say don't worry about writing it by hand if you don't have to support ABI compatibility

Thanks for the replies. I was wondering about this in context of this change: https://android-review.googlesource.com/c/platform/frameworks/support/+/2821836. @Zach Klippenstein (he/him) [MOD] I'm still wondering about the approach of not publishing

Modifier.Node

implementations, wouldn't it be useful to have as much as possible public so that external implementations can delegate to them?

If you want to support delegation, then yea, but I would only do that if you really need to. Delegation is hard to do right anyway.