Re:Secure by Design
by frou_dh on Monday March 23, 2020 @08:08AM
(#22663210)
I heard a good point about why some numeric thing in your project domain (say, InvoiceNumber) should not be a primitive int: Making it a primitive int implies that ALL the operations available on a primitive int make sense. But it can never make sense to, for example, divide one InvoiceNumber by another InvoiceNumber!
[ Parent
| on HN ]
Using primitive types “too much” is a frequent anti-pattern. It has a name: Primitive Obsession (https://wiki.c2.com/?PrimitiveObsession)
I think people do it because it is quite some work to implement proper value types in common languages like JavaScript, Java and C#.
Languages like F# or Kotlin give it to you almost for free.
The rule of thumb is exactly as you observed: if values have different semantics they should have different types.
Scott Wlaschin goes into detail about this pattern in F# both on his website [1] and in his book, "Domain Modelling Made Functional". The difference between F# and C# in this regard is quite spectacular.
[1]: https://fsharpforfunandprofit.com/posts/conciseness-type-def...
Re:Secure by Design
by gitgudnubs on Monday March 23, 2020 @06:23PM
(#22669440)
Creating perfect types for every single input is also an anti-pattern. Most of our needs fall somewhere between "works pretty well" and "formally verified". Riding herd on the type system to prove ever more invariants about your system is usually a waste of time.
It's reasonable to put a little more effort into it along API lines. But there's a reason that the compiler doesn't make it easy to define an integer type that can hold values between -7 and 923091.