We can clearly see that this design is silly, because it allows for so many invalid states. Yet when we represent some type, let’s say in Java, were so often forced to do this exact same thing. Have variables in a container of which only a certain combination is valid. And then have at most a comment saying “this number is only valid if X is also set” or “if the validity boolean is true”. Luckily Java finally has some ability for the so-called sum types now, just like Haskell’s data types or Rust’s enum types. Imo any language should have this.
Having data dependent on each other in a type means that either you have redundant data (so one of the fields should be computed) or that your container tries to be too generic (you should in this case prefer an ‘Apple’ class over a ‘Fruit’ class with an enum field ‘Type’)
We can clearly see that this design is silly, because it allows for so many invalid states. Yet when we represent some type, let’s say in Java, were so often forced to do this exact same thing. Have variables in a container of which only a certain combination is valid. And then have at most a comment saying “this number is only valid if X is also set” or “if the validity boolean is true”. Luckily Java finally has some ability for the so-called sum types now, just like Haskell’s data types or Rust’s enum types. Imo any language should have this.
Having data dependent on each other in a type means that either you have redundant data (so one of the fields should be computed) or that your container tries to be too generic (you should in this case prefer an ‘Apple’ class over a ‘Fruit’ class with an enum field ‘Type’)