Support multi-file smart contracts (debugging)

The compiler should support smart contracts that are spread over multiple .java files.

Because Java does not have functionality like C# provides with the keyword partial, another solution is needed for enabling multi-file contracts.
Our proposal is to use an annotation which has a name or ID attribute. That annotation is then applied to every class that is part of the smart contract and the compiler can determine using the name/ID of that annotation if two or more files belong to the same contract.

[csmuller]

The className or classNames attribute should contain the “invokable” smart contract class name… and not all the dependencies of that smart contract. That’s how I think about it, ideally.

Yes, i was imagining the same. The contract class is like the entry point to the compilation and the other classes will be processed because the contract class makes use of them. The helper/dependency classes will be discovered automatically because they will be in the classpath of the ClassLoader passed to the Compiler.

However, nothing prevents us to start small: maybe we can list all the classes, and automatically identify which class is the “invokable” one.

I’m not a huge fan of automatically identifying it because I think the developer gets a clearer picture if she actually has to state which class is the contract class.

[gsmachado]

That does not seem intuitive at all. There should only be one main contract class file that holds all public (invokable) contract methods.

Ok, I agree with this argument: so, the definition of a smart contract in Java, is: “a .java file which contains, among other information, all ‘invokable’ methods which users might interact with”

That doesn’t mean that all contract functionality has to be in the same file. The compiler should still support multiple files (and classes). The files besides the main contract class contain classes that encapsulate parts of the contract’s logic. Custom objects used in the contract for organizing data can also live in their own files.

Yes… so, it means that: all other .java files are “dependencies” of the smart contract, and should be also compiled and “embedded” to the final .avm. Right?

The step to smart contract libraries support isn’t far from here.

Absolutely. I also think that we’re not far from it! 🚀 ⭐