Copy translation, redux

[serras]

Continuing the discussion at #55, we've implemented a first version of the "copy from others" feature, but we're not 100% happy with it. This is an open discussion about what we want to do, and the different designs.

The problem

Good software engineering asks you to separate domain types from data transfer objects, serialization objects, and so on. Still, many people conflate both; and in many cases the main issue is that you need to write a whole bunch of boilerplate-y code to convert from one to the other.

data class Person(val name: String, val age: Int)
@Serializable data class RemotePerson(@SerialName("fullName") val name: String, val age: Int)

fun Person.toRemote() = RemotePerson(...)
fun RemotePerson.toLocal() = Person(...)

Since in many cases the field names coincide, why not generate this "copy" automatically?

The current solution: copy from parent

The current solution asks you to define a common interface and make both classes implement it.

interface PersonCommon {
  val name: String
  val age: Int
}

data class Person(...): PersonCommon
data class RemotePerson(...): PersonCommon

Then KopyKat generates code transforming the interface to each of the classes. Those are made to resemble constructors.

fun Person(from: PersonCommon): Person = ...
fun RemotePerson(from: PersonCommon): RemotePerson = ...

Problem: you need to define a common interface, and this is not always possible. Furthermore, you need to keep the interface always in sync with the actual implementors.

To and from another

Instead, one proposal is to manually state which should be the source and target of the conversion.

@CopyFrom(Person::class)
data class RemotePerson(...)

This would generate something like:

fun RemotePerson(from: Person) = RemotePerson(...)

Advantages

• no need to look around for parent types, you have full control of what you want
• you can still retain the other behavior with @CopyFrom(PersonCommon::class)

Open questions:

• should we have something to generate in the other direction? For example, in this case you would really want to have those "copy functions" as part of RemotePerson, since the domain Person should be agnostic of every serialization.

  @CopyFrom(Person::class) @CopyTo(Person::class)

  Maybe it's reasonable to conflate both into a single @Copy(Person::class)?

Isomorphic types

Another option is to indicate that you want a search to happen in the module, and generate copies with all those types which have the same set of fields. For example,

@CopyIsomorphic data class RemotePerson(...)

would look around and find Person.

Advantages

• no need to manually specify each of the classes

*Disadvantages

• not clear when a class is chosen or not, as opposed to an error when @CopyFrom doesn't work
• how to specify where to look for classes? We cannot scan the whole class path!

[pablisco]

Thanks for gathering all these 🙏

In terms of annotations, my thought are that we can have something like this:

annotation class CopyFrom(val type: KClass<*>)
annotation class CopyTo(val type: KClass<*>)
annotation class CopyWith(val type: KClass<*>)

or, if we want to be a bit more verbose:

annotation class CopyConstructorFrom(val type: KClass<*>)
annotation class CopyConstructorTo(val type: KClass<*>)
annotation class CopyConstructorWith(val type: KClass<*>)

We should look look into the option to have automatic look up. But maybe for a future version :)

[serras]

I prefer CopyFrom and CopyTo, they are shorter but still explain what they do. CopyWith doesn't sound as nice...