y9vad9 / implier Goto Github PK

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

As you can see in #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.

I think code generating should be refactored

I.e. nullable+mutable, useful for partial updates etc.

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 #1 (comment)

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
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.

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).

Currently, implier works only with interfaces, so I think that it will be great if we support abstract classes

I think it will be necessary to create something like @DSLImpl and simple java-styled builder @BuilderImpl codegenerations.

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!