data class ApiBuyer ( var id: Int? = null, ...

# language-proposals

[johnl]

data class ApiBuyer (
var id: Int? = null,
var customerId: String? = null,
var firstName: String? = null,
var lastName: String? = null,
var addressLine1: String? = null,
var addressLine2: String? = null,
var city: String? = null,
var state: String? = null,
var postalCode: String? = null,
var country: String? = null,
var email: String? = null,
var phone: String? = null,
var password: String? = null,
var status: String? = null,
var tripIdPendingRating: Int? = null,
var profileImageUrl: String? = null,
var pushToken: String? = null,
var rating: String? = null,
var ratings: Int? = null,
var isAdult: Boolean? = null,
var defaultToApplePay: Boolean? = null,
var applePayCardId: Boolean? = null,
var defaultTipPercent: Int? = null,
var promoCode: String? = null,
var tosAcceptedVersion: String? = null,
var createdAt: Date? = null,
var updatedAt: Date? = null,
var version: Int? = null
)
{
override fun equals(other: Any?): Boolean {
return super.equals(other)
}

override fun hashCode(): Int {
return super.hashCode()
}
}

[louiscad]

This snippet is nonsense. You don't need to override equals and hashcode

[johnl]

yes you do or you get the default implementation which is harmful

[louiscad]

I think you didn't understand the point of data classes. The equals and hashcode functions are implemented by the kotlin compiler, and it generates valid hashCode and equals functions taking into account all the properties of the object. Sure lombok does the same with more configuration, but JetBrains wanted to keep it simple and releasable at first

[mg6maciej]

This snippet is nonsense, because if you do override equals and hashCode you don't call super.

[mg6maciej]

And sometimes it might be reasonable to override, e.g. when you want to have equality based only on id.

[mg6maciej]

IDE also suggest to override when you have array in data class.

[miha-x64]

Also keep in mind that super.hashCode() is Object’s one, not data class’s.

[mg6maciej]

Oh... Then that code "makes" sense.

[johnl]

its intentionally objects one

[johnl]

because the generated one is a harm

[johnl]

Also you cant use equality based on id with hibernate

[johnl]

So generating this stuff as kotlin is doing is only going to cause people trouble anyway

[johnl]

And lombok users are not progressive java users in any quantity

[louiscad]

@johnl Who uses Java's serialization today?

[ilya.gorbunov]

@johnl So why do you make this class data if you do not use its capabilities, like generated equals and hashCode?

[louiscad]

@johnl There are cross-language serialization solutions such as Protobuf, Flatbuffers, Cap'N Proto, or databases that don't rely on an in-memory (understand RAM) representation and logic. Java serialization wasn't a good idea because of how painful is it to handle backwards and forward compatibility. There's no reason data classes would target serialization