One of the pillars of Domain Driven Design. I love working on a pure DDD application but I do not often convince my team (I am a constant) that this is the best way ...
Parse, Don't Validate – In a Language That Doesn't Want You To
11–20 of 107 posts
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#12[dead]
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#13[deleted]
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#14This feels right, and I also have never done it (or had the guts to get others to do it). The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right. The classic answer is to move the l…
This explosion of optionality types is (the most important) topic of Rich Hickey's "Maybe Not" talk. I recommend it!
The short version is: the shape of a type is inherent to the type itself, but the optionality of its members is dependent on the situation. A type system that solves this problem separates these concepts to allow for this distinction.
I _suspect_ it's possible to implement something like that in typescript but I haven't tried it myself (and I doubt it's very ergonomic).
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#15We should make authors disclose how much AI was used to write an article. This reeks of Opus 4.8.
Why should they disclose how much AI was used to write an article?
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#16[flagged]
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#17Zod is by far the most ergonomic way to express those ideas in TypeScript these days. I miss it when writing code in other languages.
The friction with the rest of the ecosystem is real, though. Most code out there expects you to handle errors with exceptions.
I get the impression that polymorphic return types could get in the way of JSC/V8/SpiderMonkey's JIT, but I haven't measured it and I'm not sure of the actual impact on hot and cold paths. Same for all the allocations caused by custom Option/Result implementations.
I think using Zod at the edge (with branded types and whatnot), while keeping return types as T/Promise to keep a sane relationship with the ecosystem is a good middle ground.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#18One of the pillars of Domain Driven Design. I love working on a pure DDD application but I do not often convince my team (I am a constant) that this is the best way ...
> I am a constant
What did you mean by that? You don't accept mutability or any inputs on your state of mind?
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#19We should make authors disclose how much AI was used to write an article. This reeks of Opus 4.8.
Why should they disclose how much AI was used to write an article?
If nothing else, it should be done as a courtesy to those who would like to avoid such content.
If the result is better for having used AI, why wouldn't an author want to disclose it?
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#20Is there benefit of using this branded type over just encapsulating the raw string in a private variable in closure or class? This feels a bit like forced nominal typing. The Email type doesn't have to be a string, it can be encapsulated so that invalid Emails are not representable.