4 ms·
Really ugly way to avoid something already solved by named parameters and/or namespacing
by foooorsyth 2y ago
Really ugly way to avoid something already solved by named parameters and/or namespacing
- demurgos 2y agoThis is more about nominal VS structural typing. I don't see how named parameters or namespacing would prevent accidental structural type matches.
- culi 2y agoTypeScript is a structurally typed language on purpose. But even then nominal features already exist that would have solved this problem much more elegantly. Such as `unique symbol` https://www.typescriptlang.org/docs/handbook/symbols.html#unique-symbol https://www.typescriptlang.org/docs/handbook/symbols.html#un...
- mattstir 2y agoDid you... read the article?
- beeboobaa3 2y agoYou might need to read the article again, because those things are unrelated. Or you should explain what you mean.
- foooorsyth 2y agoI read the article, thanks. It makes the claims that (1) a string of a specific form (a hash) could be misused (eg. someone might call toUpper on it) or (2) passed in incorrect order to a function that takes multiple strings. Named parameters / outward-facing labels (Swift) completely solves (2). For (1), the solution is just ugly. Just use the type system in a normal manner and make a safe class “Hash” that doesn’t allow misuse. And/or use namespacing. And/or use extensions on String. And/or add a compiler extension that looks like outward-facing labels but for return types. So many cleaner options than this nasty brand (yes, that’s the point of the article, but the solution is still hideous. Make it elegant).
- aidos 2y agoRespectfully disagree on the elegance. This looks pretty neat to me: type Hash = Branded<string, "Hash">;
- beeboobaa3 2y agoThe point of branded types is, among other things, that you do not need to introduce a wrapper class which consumes additional memory.
- throw156754228 2y agoReally? I'm surprised you mention memory is even a consideration, never even heard it raised as far as typing choices are concerned.
- beeboobaa3 2y ago(More than) doubling the memory required for all of your integers would be silly. You could use `{userId: 12345}` everywhere, or you can use a branded type and it's just `12345` at runtime.
- golergka 2y agoAre you worried about compiler memory consumption? Because it's not a class, it's a type, and it's erased at compile time.
- beeboobaa3 2y agoRuntime. Not compiler.
- golergka 2y agoNone of this exists at runtime.
- 2y ago