21–30 of 175 posts
I think I like the duck typing in TypeScript more than I dislike it. But I still wish I could say “this function accepts a type called RobotName. It’s a string, but so is RobotUuid, and we don’t want that. So only accept, strictly, objects typed as RobotName.”
Here there is an interesting article about doing this in typescript (not affiliated)
I'm confused how this was able to give out money before the new code was submitted to production. The author claims that both she and her coworker tested it before the code was submitted and they ended up with the extra $25k. Was this code only executed on the front end? Were there no checks in the backend to prevent employees from just pulling out whatever money they wanted?
if there's old_func and new_func, and the new_func call in the else was added that morning, why would the same error of new_func getting the wrong amount of arguments happen weeks before?
I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.
Seeing functions with 5-6 positional arguments makes my skin crawl even if they have strong types.
I think I like the duck typing in TypeScript more than I dislike it. But I still wish I could say “this function accepts a type called RobotName. It’s a string, but so is RobotUuid, and we don’t want that. So only accept, strictly, objects typed as RobotName.”
It felt like a lot of busywork, but it did prevent some classes of bugs.
> This is yet another reason why I say bare numbers can be poison in a sufficiently complicated system. In Racket, I tended to use keyword arguments, and include the units in the keyword argument. For example, one library used `:velocity-mm/s`. (The `/` character is an identifier constituent, not some special operator syntax.) In Rust, I'm going to try out using language features for static checking of some units (wi…
The newtype pattern in Go is easier to use, but isn't strict enough - your wrapped string can still appear directly in a string concatenation without a cast. Any wrapped integer can still be used to index a slice! Considering how careful the language is with mixed arithmetic (can't add uint8 to uint16 without casting) this feels like an oversight.
I think I like the duck typing in TypeScript more than I dislike it. But I still wish I could say “this function accepts a type called RobotName. It’s a string, but so is RobotUuid, and we don’t want that. So only accept, strictly, objects typed as RobotName.”
You can kind of do it: interface RobotName { value: string; type: "RobotName"; } Or if you don't want to make an extra wrapper around every object: interface RobotName { _phantomType: "RobotName"; } function makeRobotName(name: string): RobotName { return name as any as RobotName; } function getRobotName(robotName: RobotName): string { return robotName as any as string; } Presumably V8 is smart enough to inline the w…
Where are the unit tests?