3 ms·
The F# post argues for marking OptionalStrings, but that’s bad design. There’s basically never a real distinction between string absent and string blank and if
by earthboundkid 6y ago
The F# post argues for marking OptionalStrings, but that’s bad design. There’s basically never a real distinction between string absent and string blank and if somehow your domain did have that distinction, you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever.
- cratermoon 6y ago> There’s basically never a real distinction between string absent and string blank Oh, child. If someone came to me claiming that something not existing was the same as that thing existing but being empty, I might be inclined to refer them to a remedial course on logic.
- earthboundkid 6y agoGive a business example for a string specifically being modeled where blank is valid and distinct from null which isn’t better represented by a separate column for entry state.
- cratermoon 6y agoThere are more things in heaven and earth, Horatio, than are dreamt of in your philosophy
- earthboundkid 6y agoI too can quote something instead of addressing the topic of discussion. “Shimmy shimmy ya shimmy ya shimmy yay.”
- lmm 6y ago> There’s basically never a real distinction between string absent and string blank On the contrary, this comes up all the time; there are plenty of times when blank really is a valid value, and even if blank isn't a valid value, abusing it as a representation for "unknown" is bad for all the usual reasons in-band signalling is bad. > you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever. An actual sum type is a million times better than using two awkwardly coupled fields. Type systems without sum types are a joke and there's no excuse for using them in the current millenium.
- earthboundkid 6y agoGive examples. I have never seen a case where there was a business reason to distinguish a null vs blank string. Dates? Yes. Numbers? Yes. Strings? Nope, never. Let’s start with the most common false example: middle names. What are you going to do differently in your app if some one has an unknown vs a blank middle name? … Nothing. The displays will be the same. The search will still have to account for ignoring middle names because missing middle name might show up as “NMI” in an external system. There are no implications to having a missing middle name vs no middle name. You might need a flag for “date that the user verified that this is their full name” but that has nothing to do with null strings.
- lmm 6y agoError message "" is very different from no error message. Any legitimate use case for a null/absent string is an example; all those use cases are arguable and domain-specific, but they're a different thing from blank. For example if you're using null/absent to represent "unknown" then your search behaviour should be different from empty - for your example of middle names, a search with first=William/middle=Henry/last=Gates should return records with middle=null, but should not return records with middle="".
- earthboundkid 6y agoWhy would you send a blank error message? Surely you would at least send “Unknown error”.
- lmm 6y agoYou probably wouldn't send "hlcrkorluatnsuh" either. But using that to represent "no error" would still be a bad idea.
- earthboundkid 6y agoI don’t understand what the structure you’re proposing is. There are a lot of ways of doing form validation. Typically you’ll have field levels errors and form level errors. In those cases, the no error state is represented by an empty list. I have never seen errors represented in a way that null means no error but blank string means unknown error. That would be a weird way to represent it.
- giantDinosaur 6y agoThis reminds me of using DynamoDB, which didn't (until recently) accept the empty string as a value, instead helpfully offering to change it to null. However, there was a clear difference between a field in our database that a user had intentionally left blank and null as in the missing value which was usually indicative of some kind of scripting, API, or validation error. It is rather annoying that these assumptions get made.
- cratermoon 6y agoLots of programming languages treat 0 and null as the same thing. Numeric database columns, however, do not. This has resulted, at one of my employers, of a mix of different languages and systems treating 0 and equal to null. Sometimes, but not always. That inconsistency is a source of a fair number of bugs.
- earthboundkid 6y agoNumbers are totally different than strings. 0 is a distinct number in a way that blank is not a distinct string.