As you can see in https://github.com/y9vad9/implier/pull/10 I've added marker interfaces like Mutable<T> to allow slightly generic use of the generated APIs but in practice it would be far more useful if

@ImmutableImpl
@MutableImpl
interface Sample {
    val sample: String
    val number: Int
}

generated:

interface MutableSample: Sample {
    override var sample: String
    override var number: Int
}

class ImmutableSampleImpl(
  public override val sample: String,
  public override val number: Int
) : Sample

class MutableSampleImpl(
  public override var sample: String,
  public override var number: Int
) : MutableSample

Would happily update my PR to include this one.

Nice work! Thought best to try contributing for my personal needs VS forking. This WiP PR adds support for generating DTOs, i.e. #9 nullable mutables that can be used for partial updates, e.g.

@FactoryFunctionImpl(Visibility.INTERNAL)
@ImmutableImpl(Visibility.INTERNAL)
@DtoImpl(Visibility.INTERNAL)
@MutableImpl(Visibility.INTERNAL)
@BuilderImpl(visibility = Visibility.INTERNAL)
@DSLBuilderImpl("sampleDSL", type = DSLBuilderImpl.Type.WITH_ACCESSORS, visibility = Visibility.INTERNAL)
interface Sample {
    val sample: String
    val number: Int
}

Will generate:

internal class DtoSample(
  public var sample: String?,
  public var number: Int?
) : Dto<Sample>

internal fun Sample.toDto(): DtoSample = DtoSample(sample, number)

internal fun Sample.toPatched(patch: Sample): Sample {
  val isMutable = this is MutableSample
  val base = if(isMutable) this as MutableSample else this.toMutable()
  patch.sample?.let{ 
    base.sample = it
  }
  patch.number?.let{ 
    base.number = it
  }
  return if(isMutable) this else base.toImmutable()
}

The toPatched shouldn't be so dependent on the generated MutableSample of course, see https://github.com/y9vad9/implier/issues/11

Generated code should be better. I suggest next:

• adding kdoc to generated properties / functions from primary class / interface.
• hiding DSL Implementation behine some interface:

  // note: just example name, you can change it via annotation argument
  fun buildSample(block: SampleDSLScope.() -> Unit) = ...
  
  interface SampleDSLScope {
      public fun setName(name: String)
      public fun setDescription(description: String)
  }
  
  internal class SampleDSLScopeImpl : SampleDSLScope { ... } // or we can implement it in function as anonymous object
  

Describe the bug I have multimoduled project where I use implier. When I am trying to use generated entities I got next error:

Cannot access 'com.y9vad9.implier.GenericMarker' which is a supertype of 'com.x.DtoUserEntity'. Check your module classpath for missing or conflicting dependencies

To Reproduce Steps to reproduce the behavior:

1. Create two modules
2. Make a generation of some entity in module a.
3. Implement a in b and use entity.
4. See error

Expected behavior I think it shouldn't expose implier dependency.

Is your feature request related to a problem? Please describe. I'm using implier for generating database-related entities. My case is to not generate mutable property of identifier (I am not supposed to change it), but to make other properties mutable.

Describe the solution you'd like Probably, we need to have annotation for such stuff. For example ShouldNotMutate or using existing Immutable annotation.

Describe the bug toPatched function requires Mutable variant of entity even though it doesn't need it. It generates next code:

public fun UserEntity.toPatched(patch: UserEntity): UserEntity {
  val isMutable = this is MutableUserEntity
  val base = if(isMutable) this as MutableUserEntity else this.toMutable()
  patch.id?.let{ 
    base.id = it
  }
  patch.firstName?.let{ 
    base.firstName = it
  }
  patch.lastName?.let{ 
    base.lastName = it
  }
  return if(isMutable) this else base.toImmutable()
}

To Reproduce Steps to reproduce the behavior:

1. Create entity with annotation DtoImpl without using MutableImpl (use ImmutableImpl)
2. Run generation
3. Try to build the project
4. See error

Expected behavior I think it shouldn't use mutable variant (almost useless) at all or use it only when mutable variant is available (if we don't need producing instances).

Would be great if

@MutableImpl(annotationPackages = [foo.Bar::class])
interface Sample {
   @foo.Bar
    val sample: String
   @get:foo.Baz
    val number: Int
}

generated

class MutableSample(
   @foo.Bar
   public override var sample: String,
   @get:foo.Baz
   public override var number: Int
) : Sample

Happy to add a PR!

The most complex thing here is how to design validators. I see three ways:

• (Not convenient for me, but still the way) design it with notations and annotations:

  // object here is notation, we assuming that user will
  // create object here, but not class. Anyway this will
  // be checked at compile time
  object NameValidator : Validator<String> {
      override fun validate(value: String): Boolean = ...
  }
  
  @Validate(NameValidator::class)
  val name: String = ""
  

• (Not convenient for me, but still the way) design it with function name notations:

  var name: String = ...
  fun _checkName_(): Boolean = ...
  

  Transformed to →

  private var _name: String
  var name: String get() = _name set() = if(/* code from _checkName_() */) ... else ...
  

• (Now I'm looking forward this) Wrap it with a type:

  val name: Validate<String> = Validate(default = ...) { name -> require(name.length in 1..30) { "Provide a correct name" } }
  

  Transformed to →

  var _name: String = default
  var name get() = _name set() = if(/* code from name.validate() */) ... else ...
  

Originally posted by @y9san9 in https://github.com/y9vad9/implier/issues/1#issuecomment-984492558