but I m not sure what you mean by work as expected here you

Question

but I m not sure what you mean by work as expected here you want `a == b` to pass when a and b are of different types and may have fields that aren t included in the comparison

Nir · Answer

In truth I never used them polymorphically in python so I don t know what the result would be

Nir · Answer

that said I also have no interest intention of using them polymorphically

Nir · Answer

I just want to reuse the fields

Nir · Answer

Otherwise you have a situation where you are repeating the same things

Steve · Answer

so

Steve · Answer

duplication is cheaper than the wrong abstraction

Nir · Answer

Right so I m asking if Kotlin has the right one

Nir · Answer

if the answer is no then that s an answer sure However having the right abstraction is possible e g like python s dataclass

Steve · Answer

I don t think that is the right abstraction

Steve · Answer

I would say if they re not related otherwise then just duplicate

Nir · Answer

I mean it s clear it s readable it does what I need it do it avoids repetition

Steve · Answer

avoiding repetition isn t the highest goal though

Nir · Answer

No but it is one goal

Steve · Answer

not really

Nir · Answer

Not really interested in debating this point

Burkhard · Answer

Maybe inheritance is the wrong tool here Maybe you should go with composition If the related fields can be group logically create a data class with them Both of your classes can than have a property of that type This fixes your equality and code duplication problem

Steve · Answer

tying yourself into an inheritance chain that doesn t really fit and is just there to avoid repetition can be a worse problem than repetition

Nir · Answer

< Burkhard> I agree in principle composition is more correct the problem is that it nests the data one level further

Nir · Answer

Sometimes that is the way to go but sometimes you may be constrained already

Burkhard · Answer

And sometimes it s best to just have 2 classes with the same fields if they are not related directly

Nir · Answer

< Steve> Sure that is possible or not possible So far having used this approach in python I ve never seen any downside in practice

Nir · Answer

< Burkhard> Sure maybe that is the best solution I was just trying to understand if Kotlin offers anything better

Steve · Answer

if a and b are different types there is a very good chance that they will want to change independently locking them into an inheritance chain makes that much more difficult

Steve · Answer

so to answer your question composition is what Kotlin would offer here

Nir · Answer

Curious if Go style embedding has ever been considered in Kotlin Basically we want to reuse data fields at top level but don t want inheritance which is kind of what embedding is from what little I know of Go

Steve · Answer

or just having the two fields duplicated as they re not really the same field if those two classes are not semantically the same

Nir · Answer

< Steve> Sure and if you re free to design how the data you re modelling looks like composition is good but in this case I can t nest the data

Steve · Answer

you can always have accessors

Nir · Answer

Not sure what that means They have the same names the same types and not it s not a coincidence so I would consider them the same fields

Steve · Answer

if a and b are not interchangeable they re not the same fields

Nir · Answer

Not really sure what you mean by interchangeable in this context

Steve · Answer

Following the Liskov Substitution Principle

Nir · Answer

In that case I m not sure what A and B are

Steve · Answer

the two classes that you want to have inherit from a parent to reuse some fields

Nir · Answer

those two classes don t have a base derived relationship

Steve · Answer

but you re trying to give them one

Nir · Answer

no A and B have a common base they are not the base child of one another so LSP does not apply between A and B

Nir · Answer

< mikehearn> I m not actually sure what the right behavior would be for equality between instances of different types It could either not compile or return False both of those are fine I think

Steve · Answer

what about the issue where they re both cast to the parent class

Nir · Answer

Equality works as expected I meant only that the derived types can compare between instances and it works as you d expect i e the values of the base fields are included in the comparison

Nir · Answer

If you explicitly cast both to the parent class then it should do a normal parent class comparison i e either True or False depending on all parent fields matching

Nir · Answer

Seems completely reasonable

Nir · Answer

by doing the cast you re explicitly asking only the parent part to be compared

Steve · Answer

so two instance that are the same type but normally wouldn t be equal should be equal just by casting them

Nir · Answer

At least that s one reasonable approach Another approach would be to implement equals such it first checks if the two instances are really the same type if not return false if yes then proceed with comparison basically typical double dispatch visitor

Steve · Answer

I think that s more work than just duplicating the fields

Nir · Answer

I mean this isn t any work for the person writing the dataclass

Nir · Answer

this would happen automatically of course

Nir · Answer

the person writing the classes just writes out the 3 dataclasses and nothing else

Nir · Answer

At any rate I can see that the answers to these are a bit awkward in a statically typed single dispatch language That said it s still a bit unfortunate I use this in python quite frequently and it s quite handy I actually never use the base for anything but reusing the fields in this situation

Steve · Answer

especially in statically typed languages in general that s considered bad OOP practice

Nir · Answer

what s bad OOP practice

Steve · Answer

inheriting just to reuse fields

Steve · Answer

or functionality

Nir · Answer

Sure the problem is that in most cases using composition is just as simple so people were blatantly overusing inheritance when they had another language tool in front of them that solved the problem better

Nir · Answer

The problem is that there are situations where composition doesn t quite work out or is annoying and full of boilerplate

Nir · Answer

Inheritance maybe isn t ideal either but it may still be better in composition

Nir · Answer

Needing to model data in this case that s repeated but flat in different places composition doesn t work out

Nir · Answer

hence why I think embedding is a great idea despite not liking Go much in general

Steve · Answer

in that situation it s usually better just to have each of those classes have their own version of it

Steve · Answer

but back to what you want it doesn t seem like Kotlin offers that

Nir · Answer

I mean it is fine to say that s the best solution in Kotlin as it stands Less fine to say that s the best solution because Kotlin isn t capable of factoring out this duplication

Nir · Answer

Yeah it seems like not I was hoping maybe kotlin had something fancy akin to macros but I suppose not