E.g…

val property: KProperty1<Fruit,Double> = getThePropertySomehow()
val fruit : Fruit = getTheFruitSomehow()

val newStateOfFruit = property.copy(fruit, 1.0) // What do I have to do here instead of this made up API call?

Given a reference to a property of a data class

I was not thinking of that scenario. Is that a real use case? I mean, when one dynamically gets a reff to a property? I would use an array instead of those properties then and updated by index

I think lenses provide a way to easily modify nested data structures

I have exactly that scenario -- I obtain a subset of the fields of a data class as "updates" from an external API. I then apply these updates to a data object using reflection to convert the values to the correct type based on the

KProperty

information, and then to execute the copy constructor for the updated fields.

It could be that those types of scenarios are better suited to other paradigms. 🙂

@fellshard: It allows me to leverage all the advantages and type-safety of data classes, without writing any boilerplate code to handle updates. An

@Updateable

property annotation specifying what can be updated and what can't and it all fits together nicely. What other paradigm(s) were you thinking of?

Given flexible schemas, a more dynamic language may be suitable. You could still enforce properties for your inputs, but without top-level types. Initially, Lisp family comes to mind. JS or TypeScript or that family may also work in this scenario (emphasis on may)...

The schema isn't flexible. That is why I use data classes, with strongly typed properties (including nullability information). Only updates are flexible. For example, a data class might have non-null properties

a

,

b

, and

c

, but it is possible to only update

c

, therefore one can't use the same data class for the update.

Functional + lenses?

Yeah essentially my reflection-based call to the copy constructor is my lens. Because Kotlin doesn't support this out of the box.

Yeah, maybe something more strictly functional would work.

I don't know much about lenses as used in Haskell -- not sure if they can operate on the target object without prior knowledge of which properties are going to be changed i.e. without writing boiler-plate code for every single updateable property -- this latter requirement is the tie back to the

KProperty

and copy constructor

I think KProperty and KMutableProperty were the closest I saw to that kind of construct, but all that reflection's gotta cost unless you're smart with it, I'm guessing...

@rocketraman: if I understood you correctly, you have a huge data structure (a tree?) and you receive updates for it in a dynamic form (json maybe?)

for that scenario I would have a method on the tree nodes which would (recursively) update itself and the nodes below it

It may use reflection to know the names and types of its properties, but that would be a one-time thing on the start up or initialisation. As I understood, your implementation is more generic and uses reflection on every update.

overall, I have a feeling that this is NOT what Scala people call "lenses" due to its dynamic nature

the solution I described is easily implementable, especially now when data classes may inherit state

@voddan: Close enough on the data structure and bingo on the JSON updates (transformed to

Map

). I like the idea of using reflection only once on initialization -- that sounds promising. Thinking about implementation: each type could use reflection to create a lambda for each of its properties to (recursively) convert from the JSON value to the property type. Updates would then use the pre-created lambda rather than reflection for the type conversion. Then each type would call its own

copy

function with the result of calling every property update lambda and the update

Map

. Is that what you had in mind?

If so, it would involve a bunch of boiler-plate code in every data class, but the trade-off would be better performance.

@voddan: You are right that this is not what lenses are, which certainly involve zero reflection

The basic problem is this: JSON mappers like Jackson do

(Map<String, Any>) -> T

. I want to do

(Map>String, Any>, T) -> T

where the T input provides the properties that are not present in the Map.

I am ignoring some complexity here: I also want to do things like specify which properties can be in the

Map

... and be able to do things like

updateMap.onChanged(T, T::someField) { ... }

.. and a few other things.

Here's my JVMLS talk on coroutines, it doesn't add much to what's there in the proposal, but for some people listening works better 🙂

^^listening 45 minutes is definitely better than reading a wall of text for 868 linessimple smile

@abreslav: I would add the talk (or at least the slides) to the repo with the propolsal

@rocketraman: since you already use reflection, why do you get the boiler plate from?

the same algorithm should work for all your data classes. Implement it in one common super class (or interface) and reuse the logic

The boiler-plate is the call to the copy constructor. Do you have a way to eliminate that without using reflection?

what I have in mind calls ones the copy method of the root of an object tree, and it calls all the other copy methods on its own