In Dart, A ∪ B != B ∪ A
The title is misleading, other languages are prone to this gotcha. At least that's less deceptive than "Hot mathematician refutes conjecture with a weird trick".
Stepanov answers (*) that basic math properties should be respected, all the more nothing forewarns the possible asymmetry of the addAll operation.
If it's ill formed, shouldn't the langage tell you? C++ would reject that at compile time.
Nevertheless, the commutativity of union isn't, breaking the consistency.
Julia Belyakova's paper notes that dependent types allows models consistency by letting the comparer be a part of the type.
Does it suggest that C++ templates can encode dependent types? If not, it means that models consistency relies on a sub-property of dependent typing.
x in (A ∪ B) = (x in A) or (x in B)
We could hear the perfect symmetry. Related: you cannot code isEmpty.
This will be the subject of another post.
Thank you for your attention,
Warm regards.
(*) His book was travelling with me.
Be amazed
People stop me in the subway arguing it's contrived or even ill formed.Stepanov answers (*) that basic math properties should be respected, all the more nothing forewarns the possible asymmetry of the addAll operation.
If it's ill formed, shouldn't the langage tell you? C++ would reject that at compile time.
Model consistency
You could consider this behavior as perfectly fine since the respective models of d1 and d2 (sensitivity to the case) are preserved.Nevertheless, the commutativity of union isn't, breaking the consistency.
Julia Belyakova's paper notes that dependent types allows models consistency by letting the comparer be a part of the type.
Does it suggest that C++ templates can encode dependent types? If not, it means that models consistency relies on a sub-property of dependent typing.
True union
As a side note, the true OO flavor of union, which is also the true functional approach, does not exhibit this issue:x in (A ∪ B) = (x in A) or (x in B)
We could hear the perfect symmetry. Related: you cannot code isEmpty.
Thinner models
Anyway a better approach would be to associate the comparer not the set but to the functions acting on it.- More orthogonal. You could perform both case-sensitive and case-insensitive queries on the same set.
- Less code duplication.
This will be the subject of another post.
Thank you for your attention,
Warm regards.
(*) His book was travelling with me.
Comments
Post a Comment