4 ms·

That's a very clear example. But what if I instead wrote: const accountId = AccountId ("125314" ); There would be the needed checks and balances in the fu

• svieira 3y ago
  Yes, but then there would be runtime overhead for the wrapper (presuming a class or object is returned) or the type of accountId would be the underlying type (if AccountId isn't returning a branded type).
• cush 3y ago
  I personally prefer less code and more explicit casting
  • whilenot-dev 3y ago
    const accountId = "125314" as AccountId; or const accountId = new AccountId("125314"); or const accountId = accountIdFromString("125314"); is all "explicit" casting in my understanding, one way or the other, and the first ... as ... being on the lowest level. I'd rather go for something like "do the casting close to the source, and in general use 'parse, don’t validate'[0] when getting input from the outer world". [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
    • cush 3y ago
      Agree. I was talking about const accountId = AccountId (“43525”) being less explicit
    • usrusr 3y ago
      The as also does not burden the reader with guessing about the absence of unexpected stuff happening in the functions. Don't pepper the code with mostly unused hidey-holes just to perhaps save some busywork later. If you do add valuation, make it an honest asValidatedAccountId("123"), not an accountIdFromString("123") that may or may not do more than casting. (PS, very much off topic: speaking of hidey-holes, are any of the AOP monstrosities still operational?)