31–40 of 43 posts
I work in a slightly different context but have dealt with a similar problem. I build Unity3D apps and I write a lot UI for the editor that affects how things are serialized. I've stopped serializing enums due to being burned too many times. When people: -Add entries not at the bottom -Rename entries -Remove entries -Rearrange entries So instead I made a kind of data-driven enum that you create through the editor. Ea…
I don't think I've used it to describe true or false though. Possibly as a third option, but the names for the options end up well described, not just true and false.
Looking back, I'd much prefer to make lots of types, describing the object along the way. In typescript it would be real easy to describe too, just &-ing the steps' results to be main object along the way
I work in a slightly different context but have dealt with a similar problem. I build Unity3D apps and I write a lot UI for the editor that affects how things are serialized. I've stopped serializing enums due to being burned too many times. When people: -Add entries not at the bottom -Rename entries -Remove entries -Rearrange entries So instead I made a kind of data-driven enum that you create through the editor. Ea…
Do you load this entire table into memory or do a db/cache lookup every time?
Note that in my applications the names are not known at runtime because comparing the guids is sufficient and these drop downs are not shown to the user but only the designer.
Were I employing this system in a more distributed fashion I might reconsider packing the names with guids understanding of them to be frozen after build.
I'm also considering a method to allow an engineer to limit the scope of key so that the designer is presented with a subset and not aall of the key options when setting the value.
I've seen some terrible implementations in Java abuse Boolean as a tri state value: true, false, null. However, this always caused bugs because you'd end up with terrible code patterns. For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default? I think "unset" is a state to be generally avoided because it's bound to create problems for you down the line. Personally, I prefer…
This is a common strawman used to advise against null.
Null only means one thing. Null. It doesn't convey any further meaning. It is a "not set" or "not initialised" state.
It isn't a default, it isn't false, it isn't not enabled.
If you have a user interface tied to this variable. Null means not yet set.
This is entirely logical. The only people getting their knickers in a bunch are those that don't want to admit there is uncertainty and context required to determine what null means in your application.
My advice: don't apply further meaning to null other than null or not set.
TypeScript is nice because its null type is explicit. So if a type claims to be bool, it is really bool (either true or false, nothing else). For a nullable variable of type T (including boolean), the type must be explicit about it: let choice: T | null; Another nice alternative is an Option type, like Rust has. I think it would be something like Option . But those (a null, or a None, respectively) would be only choi…
And it's terrible because there's both `null` and `undefined` which have largely the same meaning but aren't equal. Depending on what you're interacting with, you may need to use one over the other or coerce. Especially common with developers from other languages who don't even know of the gotcha
I've seen some terrible implementations in Java abuse Boolean as a tri state value: true, false, null. However, this always caused bugs because you'd end up with terrible code patterns. For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default? I think "unset" is a state to be generally avoided because it's bound to create problems for you down the line. Personally, I prefer…
> For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default? This is a common strawman used to advise against null. Null only means one thing. Null. It doesn't convey any further meaning. It is a "not set" or "not initialised" state. It isn't a default, it isn't false, it isn't not enabled. If you have a user interface tied to this variable. Null means not yet set. This is en…
Earlier quoted context omitted.
> For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default? This is a common strawman used to advise against null. Null only means one thing. Null. It doesn't convey any further meaning. It is a "not set" or "not initialised" state. It isn't a default, it isn't false, it isn't not enabled. If you have a user interface tied to this variable. Null means not yet set. This is en…
I think people are conceptually fine with null. What they’re annoyed with is the inability to know if null is a possible value for a variable in many programming languages, e.g. Java.
Earlier quoted context omitted.
> For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default? This is a common strawman used to advise against null. Null only means one thing. Null. It doesn't convey any further meaning. It is a "not set" or "not initialised" state. It isn't a default, it isn't false, it isn't not enabled. If you have a user interface tied to this variable. Null means not yet set. This is en…
I think people are conceptually fine with null. What they’re annoyed with is the inability to know if null is a possible value for a variable in many programming languages, e.g. Java.
You shouldn't be setting nullable variables to null so far away from where they're used that they're a problem.
E.g. if you're passing around an object with a possibly null value attached you should instead set it to a default empty state, empty string, zero, false etc.
Its only in rare circumstances that you should be needing to worry about null values.
I will however concede that non nullable types are super useful. I just don't think languages should remove null entirely. E.g. some rust projects have so many options types null would have been easier to code around. I know this is down to inexperience but at that point you've lost me - inexperience with null types is the only thing that makes null types a big problem.