While the reasoning holds generally, that specific example is wrong.
The type the author presents is not the “User Profile” but a “User Profile Load Resource” (or something in those terms).
When you actually design interfaces you discover that there are way more states to keep in mind when implementing asynchronous loading.
1. There’s an initial state, where fetching has not happened yet
2. There may be initial cached (stale or not) data
3. Once loaded the data could be revalidated / refreshed
So the assumption that you either are loading XOR have data XOR have an error does not hold. You could have data, an error from the last revalidation, and be loading (revalidating).
Yup, it's quite rare that ADTs (or Rust enums) are so clear cut and obvious.
The idea that the data model looks like
enum XYZ {
case A(B, C, D, E);
case F(G, H, I, J, K);
case L();
case M(N, O);
}
is just not true in practice.
I think messaging is one case where it can happen, but even there it's often good to combine fields and share them (and common code) over multiple types of messages. If Messages A and B both have a field "creationTime" or whatever (with identical semantics), it's probably a bad idea to model them as separate fields, because that leads to code duplication, which is unmaintainable.
Maybe I can be more precise by proclaiming that ADTs can be good to be clear what's "there", so they can be used to "send" information. But to write any useful usage code, typically a different representation that folds common things into common places is needed. And it might just happen that field F is valid in cases A and B but not C. That's life! Reality is not a tree but a graph.
That's why it's a bad idea to try and model the exact set of possible states and rule out everything else completely in the type system. Even the most complicated type systems can only deal with the simple cases, and will fail and make a horrible mess at the more complicated ones.
So I'm saying, there is value to preventing some misuse and preventing invalid states, but it comes at a cost that one has to understand. As so often, it's all about moderation.
One should avoid fancy type system things in general because those create dependency chains throughout the codebase. Data, and consequently data types (including function signatures) is visible at the intersection of modules, so that's why it's so easy to create unmaintainable messes by relying on type systems too much. When it's possible to make a usable API with simple types (almost always), that's what you should do.
This will be discovered at compile time if you use immutability & types like the article suggests.
> So the assumption that you either are loading XOR have data XOR have an error does not hold.
If you design render() to take actual Userdata, not LoadingUserdata, then you simply cannot call render if it's not loaded.
The way to produce unspecified behaviour is to enable nulls and mutability. Userdata{..} changing from unloaded to loaded means your render() is now dynamically typed and does indeed hit way more states than anticipated.
I wonder if the browser would attempt to validate the contents of a script tag with type json, versus treating it as a blob that would only be validated when parsed/used. And any performance overhead at load time for doing so. Not at a machine at the moment so I can't verify.
How so? I don't remember ever having seen issues with this. If anything CSP steers you towards this (instead of inline scripts directly assigning to JS variables)
CSP blocks execution/inclusion, but since json does not execute and any json mimetype will not do execution there is no problem.
Any CSP-allowed other script can read that application/json script tag and decode it, but it is no different than reading any other data it has access to like any other html element or attribute.
The output looks terribly similar to what sci-fi movies envisioned as 3D reconstruction of scenes. It is absolutely awesome. Now, if we could project them in 3D… :)
Posted it few days ago but didn’t get any traction. All Linus’ work on retro computing is fenomenal. Please have a look at its channel, a lot of awesome content there.
Since the dissertation by Ken Thompson about compiler trustability was quoted today, I thought it would be a good idea to bring this short novel back from the archive. Loved it years ago and still is very enjoyable.
When you actually design interfaces you discover that there are way more states to keep in mind when implementing asynchronous loading.
1. There’s an initial state, where fetching has not happened yet
2. There may be initial cached (stale or not) data
3. Once loaded the data could be revalidated / refreshed
So the assumption that you either are loading XOR have data XOR have an error does not hold. You could have data, an error from the last revalidation, and be loading (revalidating).
reply