Support for nested binding

[vans239]

I am interested in ability to bind exisiting instance recursively. Based on my understanding of source code the feature currently is not supported

Kotlin example

@CompiledJson
class Container {
    var a: String = "a"
    var b: String = "c"
    var c: String = "b"
}

@CompiledJson
class Example {
    var value: Int = 1
    var container: Container = Container()
}

Example_DslJsonConverter contains something like:

public void bindContent(...){
			...
			instance.setValue(com.dslplatform.json.NumberConverter.deserializeInt(reader));
			...
			instance.setContainer(reader_container().read(reader));
			
}

Instead I'd like to have:

public void bindContent(...){
			...
			instance.setValue(com.dslplatform.json.NumberConverter.deserializeInt(reader));
			...
                        binder_container().bind(reader, instance.getContainer())
}

That way instance reading would be zero allocation (mostly)

[plokhotnyuk]

@vans239 Here is how encoders and decoders are derived recursively with the library extension for Scala.

Probably similar approach can be used with Kotlin.

[vans239]

@plokhotnyuk I am not sure that follow your idea. Dsl-json supports nested objects converters from the box. It also supports 'binding' of json into the instance, but it doesn't work recursively. The recursive support would require code generation change (aka annotation processor)

[zapov]

I probably didn't add support for this because its not obvious how to handle nested binding when not all properties are provided. You would need to do some reset() before the binding... but I guess this could be enforced by having some dsl-json signature to implement that behavior.

[vans239]

Would it be reasonable thing to add to the library? Thinking on prototyping this.

You would need to do some reset() before the binding

For auto-generated bind indeed values should be reset. Good point. For provided BindObject it should be responsibility of handling in bind method.

The alternative - require caller to reset values before binding.

[zapov]

It is a reasonable thing. And looks useful to add. Not sure when tho. I have some other changes pending too, just never the time to implement them :(

[zapov]

If you want to make a PR that would certainly move it faster :)

[vans239]

I had yesterday an issue when tried to experiment: mvn install on clean checkout fails due to tests. Similar to https://github.com/ngs-doo/dsl-json/pull/102#issuecomment-439602837

java.lang.AssertionError: expected:<NOTE> but was:<ERROR>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:834)
	at org.junit.Assert.assertEquals(Assert.java:118)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at com.dslplatform.json.DslValidationTest.checkNonNull(DslValidationTest.java:129)

Is there any chance that you know what could cause it? I can share full env setup later today

[zapov]

Without digging into I suspect it might be due to missing Mono. There are tests running the DSL Platform compiler on a subset of cases. You can exclude that project if you don't want to have Mono around.

[vans239]

@zapov I made some proof of concept PR https://github.com/ngs-doo/dsl-json/pull/243. Will appreciate feedback

[zapov]

Tnx for the PR. I found some time to work on DSL-JSON, went through your PR and merged a working version: https://github.com/ngs-doo/dsl-json/commit/b8a12fad83ff010e5f21ebd0df681a9a20d3f202 It seems there was no need for this reset I had on mind, as one can do that in the bind method. Also, I dont think there is a need for mandatory, nullable guards as we can just pass null into the method and one can just decide what to do (either call into read or take some shared instance and bind that instead).

Let me know if you think there should be some changes/improvements.

Hopefully I managed to wrap up all the things I planned and make a new v2 version based on Java8

[vans239]

That's amazing. I'll close my PR as it's not needed anymore. I'll try out the feature when v2 beta is published to maven.

one can just decide what to do (either call into read or take some shared instance and bind that instead)

I have some concerns about shared instance / pool, because that would make it tricky to use same binder multiple times in one event. So if instance not provided only safe choice is to allocate

[zapov]

v2 released. While this does support wrapper classes there is still some work for actual binding of instances, but thats a different feature

[vans239]

Could you point to v2 release? I don't see it in artifactory https://mvnrepository.com/artifact/com.dslplatform/dsl-json and releases page https://github.com/ngs-doo/dsl-json/releases

[zapov]

https://repo1.maven.org/maven2/com/dslplatform/dsl-json/2.0.0/