Is there a particular reason why we have e.g. createCmd, exerciseCmd etc. instead of just plain create/exercise?
Granted there is a namespace clash with prelude, but you can always import qualified, and I would think it good practice to keep scripts in a separate file from models in general.
2 Likes
It’s a mix of a few different things:
- DAML Script is something users encounter very early on. Initializing a ledger is something we use in a ton of example, it is useful for even the simplest apps you create yourself, …. So the entry barrier needs to be as low as possible. Qualified imports is something that you can get away with for quite a while so having to understand that to use DAML Script introduces unnecessary friction.
- Most of the rest of the DAML Script API works just fine in an unqualified way. So you will often end up having to import twice, once unqualified and once qualified or you end up having to qualify a lot of stuff for no good reason. Keeping scripts in separate files doesn’t really change anything here and while this is a good idea for things you deploy (and there it should really be in a separate package not just a separate file), for experimentation it is really convenient to just have them in the same file.
- APIs that clash with
Prelude are mostly a bad idea imho. Having to hide things from Prelude is something even fewer people understand than qualified imports. APIs that are designed to be fully qualified kind of work but still introduce more friction especially for experimenting and examples.
- Giving them separate names just makes it easier to see quickly if you are looking at client code (DAML Script) or server code (e.g. something that is intended to be executed in a choice).
1 Like