@rauschma what about this version?
```ts
type Tree<T> = [Tree<T>, T, Tree<T>]|null;
```
And if we would like to make a balanced tree for immutable containers, then we can define a BTree23:
@rauschma what about this version?
```ts
type Tree<T> = [Tree<T>, T, Tree<T>]|null;
```
And if we would like to make a balanced tree for immutable containers, then we can define a BTree23:
2/ Experiment (not yet sure if I like it):
type CTree = CTreeNode | CEmptyTree;
class CTreeNode {
left: CTree;
right: CTree;
value: string;
}
class CEmptyTree {}
// DU version:
type DUTree = DUTreeNode | DUEmptyTree;
type DUTreeNode = {
kind: 'DUTreeNode',
left: DUTree,
right: DUTree,
value: string,
};
type DUEmptyTree = {
kind: 'DUEmptyTree',
};
1/ I love #TypeScript’s discriminated unions: https://exploringjs.com/tackling-ts/ch_special-values.html#discriminated-unions
Alas, I often end up switching to classes:
A. The discriminant is not very sticky:
– There is no refactoring for renaming it.
– TS cannot infer the type of an object via a discriminant (only narrow it). In contrast to: new MyClass()
B. Classes provide locations for initialization code and operations. I could put each DU in its own module but that is often too fine-grained for my taste. Future: submodules?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.