[FEATURE REQUEST] Add a decoder for exercise events to the Java codegen

[leonidr-da]

What is the problem you want to solve?

Can we extend the Java codegen to include a decoder for choices as well as templates? From an ExercisedEvent.

This would allow us to traverse transaction tree's and write logic that depends on a specific model event as opposed to reinterpreting the structure of a general ExercisedEvent.

cc @asarpeshkar-da

[stefanobaghino-da]

Right now the Java codegen includes a decoder which allows you to translate a created event into a the generated Java representation of the Daml contract whose creation happens as part of said event. In this representation, choices are modeled as methods on the Java object that "wraps" a Daml contract

Based on what you wrote, you would like to:

1. have some kind of data representation of a choice (let's call it Choice) that has been taken, whose exact structure is expressed as a Java class generated in the same way as Contracts, with fields and/or accessor methods that allow to directly tap into
   1. the arguments of the choice
   2. the result of exercising the choice
   3. possibly (but this could be more complicated) the sequence of consequences that exercising the choice has had in terms of Choice and Contract objects, rather than a sequence of child event identifiers as in the ExercisedEvent
2. have another decoder that turns an ExercisedEvent into a Choice object

Is the phrasing I used to expand on your ask correct and complete?

[asarpeshkar-da]

I'd also like a more finely typed way of traversing the transaction tree. To the above, I'd add that the arguments and results should also use generated types rather than the generic Value AST type.

It would also be nice if the ExercisedEvent -> Choice decoder implemented a deep transformation so one could then implement a tree traversal as a bunch of type tests on Choice values.

[stefanobaghino-da]

Yes, I probably wrote it badly, but both were points I was trying to make in my reply, thanks for confirming.

[leonidr-da]

@stefanobaghino-da Yes. I think 1.i, 1.ii and 2 would go a really long way already. But once you have those, I think that you're in reach of 1.iii too, which would be awesome.

[S11001001]

Depends on:

• [x] #14313
• [x] #13768
• [x] #14329

With those we will not even need to generate any new code to support an exercise event decoder.

[S11001001]

Implementation plan for this feature:

• [ ] a builder <Z> that takes a series of pairs <Id, Arg, Res> (Choice<Id, Arg, Res>, EEv<ContractId<Id>, Arg, Res> => Z) where EEv is a generalization of Exercised to produce a stream of Z
  • [ ] a function that takes unhandled exercises to Z can be supplied as well; if undefined, unrecognized choices will simply be discarded
  • [ ] the utility that takes a single Choice<Id, Arg, Res> and produces a stream of EEv<ContractId<Id>, Arg, Res> is trivially derivable from that by simply passing identity as the function arg
  • [ ] likewise, if desired, a "callback" variant that discards results can be defined simply by setting Z = Void
• [ ] a function from ContractDecoder to ExerciseDecoder that produces untyped but codegen-classed EEvs
  • [ ] this can be defined using the above-described builder
  • [ ] it will also require extending ContractDecoder to take InterfaceCompanions as well, possibly by taking any ContractTypeCompanions, and
  • [ ] changing codegen to pass in all the INTERFACEs as well when generating a ContractDecoder subclass
• [ ] perhaps in ouroboros fashion a synthesis of these, where a fallback can be assembled that itself uses an untyped ExerciseDecoder, which uses its own builder...this implements 1(iii) from @stefanobaghino-da 's post
• [ ] #15437, perhaps

For posterity, the thing we have called Choice in the bindings now is not what @stefanobaghino-da refers to as Choice above; instead I have called the latter Choice EEv in the above plan.