The object may not have neither of the two fields.
The object may have only field1, and not field2.
Only if the object has field1, then it can have field2.
It seems to me that the way these are worded is rather confusing. I can figure it out eventually going through each line, and the #2 creates a contradiction with #3. It seems to me that if #3 is true, then #2 cannot be true.
I must be confused. You’re saying that every application should enumerate every potential combination of data, one-by-one? I don’t see where algebraic datatypes are being applied.
Enumerating every potential combination is obviously impractical. But thinking about it helps you design types in a better way so that you can reduce the amount of data that is valid. One of the principles I use when designing datatypes is looking for groups of data that are absolutely independent of each other, and thinking about them separately. Then, for the groups of data that are somewhat dependent on each other, there is usually one field that determines the others in some fashion, and I split the data based on this field.
The example applies the underlying ideas behind ADTs to look for the final solution. In Haskell, you could think of something equivalent in the style of:
data NoFields = NoFields
data Field1Only = Field1Only {
field1 :: String
}
data BothField1AndField2 = BothField1AndField2 {
field1 :: String,
field2 :: String
}
data InvalidObject = InvalidObject {
field2 :: String
}
data Fields
= NF NoFields
| F1O Field1Only
| BF1AF2 BothField1AndField2
-- Didn't put InvalidObject here
I think I understand. But this seems like an application of structural typing to enumerate permissible combinations of fields, rather than of algebraic datatypes.
It seems to me that the way these are worded is rather confusing. I can figure it out eventually going through each line, and the #2 creates a contradiction with #3. It seems to me that if #3 is true, then #2 cannot be true.
It definitely could be more clearly worded. I think it’s saying:
Thanks zzing and chenghiz for the kind suggestion! I’ll tune down the poetical approach to writing.
I must be confused. You’re saying that every application should enumerate every potential combination of data, one-by-one? I don’t see where algebraic datatypes are being applied.
Hi!
Enumerating every potential combination is obviously impractical. But thinking about it helps you design types in a better way so that you can reduce the amount of data that is valid. One of the principles I use when designing datatypes is looking for groups of data that are absolutely independent of each other, and thinking about them separately. Then, for the groups of data that are somewhat dependent on each other, there is usually one field that determines the others in some fashion, and I split the data based on this field.
The example applies the underlying ideas behind ADTs to look for the final solution. In Haskell, you could think of something equivalent in the style of:
I think I understand. But this seems like an application of structural typing to enumerate permissible combinations of fields, rather than of algebraic datatypes.