Potentially dumb question here, but what exactly is the point of reference contracts and exerciseInterfaceByKey? I understand that the reference contracts are the workaround to interfaces not currently being keyed, but we technically don’t have to use the reference contract right? If we have the key of the contract that implements the interface, couldn’t we do
or something along these lines (apologies for incorrect syntax). I get that using exerciseInterfaceByKey would reduce the number of steps that we have to do, but I guess my question is do we need to implement the reference contracts if we do something like the above instead?
your ability to exercise by key (so to speak) on any template implementing an interface, not just a specific one,
your ability to define your Daml package such that it doesn’t depend on a specific (or any) implementing templates, which in turn means those templates can be independently upgraded and vetted from the exercising Daml code, and
the ability to have independent template and interface key structures.
You lose all of these advantages when e.g. referencing Batch directly here. If you don’t need any of these advantages, you might not need interfaces at all. Accordingly, use cases that do call for interfaces typically can’t get away with your suggestion.
I’m not sure I’m following what this point meets, unless you mean for templates that do not have keys that implement the interface
Makes sense
Also makes sense
So then for canton/daml 3, is the way that exerciseInterfaceByKey works going to change? Meaning that since keys are no longer guaranteed to be unique, will it execute the choice on the first contract that it finds with the key?
Batch and IBatch refer to a template and interface, respectively, in your example. Your code works only for ContractId Batch. For any other template that implements IBatch it will fail. This is not the case for the reference contract technique; the reference contract stores a ContractId IBatch and it can be any implementing template.
If it’s present at all, it definitely won’t work in exactly the same way, and that will depend on what shape the feature takes. I would suggest, for now, if you’re interested in Daml 3 compatibility, it’s best to avoid assuming that keys will be available at all in your application architecture. For example, nothing currently running on the Canton Network, e.g. splice-amulet (branded Canton Coin on mainnet), depends on them.
For Batch and IBatch, couldn’t I do the same thing for a different keyed contract that implements IBatch? I’m not sure I’m following how (cid, contract ) <- fetchByKey @Batch batchKey iCid <- toInterfaceContractId @IBatch cid _ <- exercise iCid Choice and (cid, contract ) <- fetchByKey @Account accountKey iCid <- toInterfaceContractId @IBatch cid _ <- exercise iCid OtherChoice
would be any different from IBatch.exerciseInterfaceByKey @Batch.I batchKey Choice and IBatch.exerciseInterfaceByKey @Account.I batchKey OtherChoice
since both scenarios the contract needs to implement batch, wouldn’t these essentially do the same thing? I guess the part I’m hung up on is the ‘it can be any implementing template’. Unless your referencing a scenario where we have exerciseInterfaceByKey (EIBK) in a function that can take different templates as inputs? Then EIBK is not rigidly bound by the @Batch or @Account fetch?
If it’s present at all, it definitely won’t work in exactly the same way
