3 ms·
Ok, I can understand that logic but then you might end up with dozens and dozens of "small types" so, as far as I understand, those who try to follow that parad
by iaskwhy 12y ago
Ok, I can understand that logic but then you might end up with dozens and dozens of "small types" so, as far as I understand, those who try to follow that paradigm have no problem whatsoever with the potentially high number of these types, is it so?
(Again, asked another way, is it ever a problem to create a "small type" if it follows that rule? For some codebases it might mean having a "small type" per unique parameter on signatures.)
- Terr_ 12y ago> Again, asked another way, is it ever a problem to create a "small type" if it follows that rule? IMO the biggest problem isn't having too many distinct types, because they represent information you'd need to track manually anyway, like knowing that $time is seconds rather than milliseconds. I'd be more worried about: 1. The risk of conflicts between different groups of people who both defined their own type called called "Newtons" and want their libraries to work together. 2. The sliding-scale of inconvenience if your implementation gets in the way of the mathematics, like having to call `foo.asFloat() * 2` rather than `foo * 2`. (You can relax things a bit by relying on best-effort annotations.)
- iaskwhy 12y agoThank you for your insights, it's always great to learn new things :)