Why do `ModifierNodeElement` implementations usual...
# compose
v
Why do
ModifierNodeElement
implementations usually provide their own hashCode and equals implementations? What about using a data class?
🤔 1
f
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
v
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.
I haven't heard about avoiding data classes for libraries, is there some reasoning for that?
I'm just curious blob smile
f
there's an article from JW, let me find it
for the other question, when you develop a library, every extra method counts
z
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
v
well that's a loadful of good arguments from Jake, thanks for the link gratitude thank you
👍 1
z
Again,
Modifier.Node
implementations shouldn’t be public
2
v
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
s
I'd say don't worry about writing it by hand if you don't have to support ABI compatibility
v
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?
z
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.