[Request] A handle to turn off inline modifier in generated optic|products.

[soberich]

What version are you currently using?
0.9.1-SNAPSHOT
What would you like to see?
A handle to turn off inline modifier in generated optic|products.
Use case:
Mapping via copy method between projections to reduce boilerplate.
Achieved via inheritance by delegation. Similar as described here.
https://tp21.se/blog/2017/12/07/dto-mapping-in-kotlin/
to not to expose delegate to outside world at lease internal modifier is desirable.
Resulting

Public-API inline function cannot access non-public-API 'internal final val delegate: Record defined in com.example.marvel.domain.model.api.record.RecordDto'

Should we make a handle to turn inline off?

[raulraja]

I'm not sure there is a strong reason why we are inlining those and can probably be turned off for all codegen stuff. //cc @nomisRev

[pakoito]

This is fixed by annotating with @PublishedApi, doesn't it? It tries to inline a private and warns about it.

[soberich]

@pakoito it worked.
But now I have a different error with @product

/marvel-github/business/build/generated/source/kaptKotlin/main/product.com.example.marvel.domain.model.api.employee.employeeCreateCommand.kt: (62, 133):
 Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type Long?
e: /marvel-github/business/build/generated/source/kaptKotlin/main/product.com.example.marvel.domain.model.api.employee.employeeCreateCommand.kt: (62, 142):
 Type mismatch: inferred type is Long? but Long was expected

You can go clone this -> https://github.com/soberich/marvel and execute ./gradlew kaptKotlin to see the errors.
The project is a mess - it's a playground.
And yes, there are some nullable/non-nullable suboptimal decisions made due to other libraries and general attempt to combine them. So, there are nullable types for id because one of projections is expected to get a null (no-value) for id (...UpdateCommand).

EDIT:

And also id is a var because Hibernate requires it to be so. To have this kind of mapping projection <-> entity you need by syntax for delegation. Normally you would've make it val in interface and var if Hibernate requires in @Entity but with by syntax Kotlin compiler sees this situation as a val overrides var and raises compilation error (Idea highlights as error as well).

[pakoito]

Not supporting nullables seems like an oversight on the processor. Just for the sake of testing could you please change id from Long? to Option<Long>. How could we make that work with Hibernate?

On the philosophical level, you shouldn't use your storage format for domain, even if the mapping is almost 1:1, because of issues like this.

[soberich]

@pakoito changing the data type is not an option (sorry for the pun). This issue is about inline. Guys (@raulraja, @pakoito), if there is any move in direction of removing inline this will make sense IMO. And anyway feel free to close whether you apply proposed change/fix or not.

[pakoito]

Yes, look into the processor for optics:

https://github.com/arrow-kt/arrow/blob/master/modules/meta/arrow-meta/src/main/java/arrow/optics/LensesFileGenerator.kt#L16

https://github.com/arrow-kt/arrow/blob/master/modules/meta/arrow-meta/src/main/java/arrow/optics/IsosFileGenerator.kt#L33

https://github.com/arrow-kt/arrow/blob/master/modules/meta/arrow-meta/src/main/java/arrow/optics/OptionalFileGenerator.kt#L24

https://github.com/arrow-kt/arrow/blob/master/modules/meta/arrow-meta/src/main/java/arrow/optics/PrismsFileGenerator.kt#L14

Send a PR removing them and tag @nomisRev