Support reading from non-case classes about chimney HOT 8 CLOSED

Another use case:

Some users of jsoniter-scala ask to add support 3rd party or/and legacy with lot of Java POJOs.

Your library would allow them to use new Scala case classes that efficiently mapped to old Java POJOs in a custom way until migration or integration with new stuff is fully completed.

from chimney.

I'm not convinced whether this should be supported use case in this library, here's why:

• Chimney supports transformations in a type-safe way which requires schema information at compile-time, which we obviously can't get from native JS objects
• As you mentioned, you can still convert JS objects to case classes at runtime, but this operation reminds me kind of deserialization which can fail and this should be properly modeled in a type system; I believe it's possible to define a type-class that performs it (and even derive it for any target case class), but conceptually it's something different than Chimney was designed for.

from chimney.

Theoretically we could use something like structural types and handle transformations with them... but ATM Scala.js doesn't support structural types for native JS code. I think the type-safe bindings from JS to Scala.js is kind of a Scala.js domain, if it supports them, then Chimney could do something more than it does currently. I'm afraid it cannot help you with what you want to achieve.

from chimney.

I think there may be some confusion about this request. I'm not trying to use chimney to go directly from js.Dynamic to a case class. I'm defining explicit facade traits and classes. So everything I'm working with has static types. However, the facade mapping types have fields with JS specific types (js.Date instead of OffsetDateTime, UndefOr instead of Option, js.Array instead of Seq, etc.) So I want to convert from the facade types to case classes with types I can share with the JVM.

I'm currently using chimney to do this conversion. I just have to manually map all of the fields because chimney doesn't automate as much if you aren't working with case classes.

from chimney.

I think there may be some confusion about this request

I wasn't used Scala.js for long time and wasn't aware they provide facades over native JS objects. But this sounds like a game changer.

Facade traits/classes seems to be usual scala language constructs which we can statically inspect within a macro. Currently we limit transformer derivation to case classes, because it's easy and obvious how to determine list of their parameters and construct the target object. But we could think of relaxing this to wider range of classes, not necessarily scala.js facades only.

As you noticed, there would be slight difference between (1) transforming from arbitrary class to case class and (2) transforming to non-case-class target.

First scenario seems to me relatively easy to achieve - we only need to generalize how we collect accessible fields in the source type, leaving generation of target code unmodified.

However second case requires us to invoke target constructor matching the class signature (possibly multiple parameters list) and requiring values to provide (override) for all abstract members (including inherited ones). Consider such an example:

trait Base { def x: Int }
abstract class Foo(y: String)(z: Double) extends Base {
  def v: Int
}

// object creation code has to look similar to:

new Foo(src.y)(src.z) {
  val x: Int = src.x
  val v: Int = src.v
}

That sounds much more complex to implement properly and I'm not sure even if people would use the library in that way.

Regarding (1) - I'm open to go that way as it may provide real value with relatively small cost. @asdcdow, would you like to contribute with PR and/or bunch of code examples that we could put into tests?

from chimney.

I can definitely provide code examples for tests. I'll see if I can put together a pull request in the next couple of weeks. It might take me a little bit due to time constraints and the fact that I haven't written any macros before.

from chimney.

Sure, sounds good. Let me know if you need some hints how to start or when you stuck somewhere.

from chimney.

Java beans reading support added in #81. For writing support there is #87.

from chimney.