| OLD | NEW |
| 1 // Copyright 2015 The Chromium Authors. All rights reserved. | 1 // Copyright 2015 The Chromium Authors. All rights reserved. |
| 2 // Use of this source code is governed by a BSD-style license that can be | 2 // Use of this source code is governed by a BSD-style license that can be |
| 3 // found in the LICENSE file. | 3 // found in the LICENSE file. |
| 4 | 4 |
| 5 class AbstractNode { | 5 class AbstractNode { |
| 6 | 6 |
| 7 // AbstractNode represents a node in a tree. | 7 // AbstractNode represents a node in a tree. |
| 8 // The AbstractNode protocol is as follows: | 8 // The AbstractNode protocol is described in README.md. |
| 9 // - When a subclass is changing the parent of a child, it should | |
| 10 // call either parent.adoptChild(child) or parent.dropChild(child) | |
| 11 // as appropriate. Subclasses should expose an API for | |
| 12 // manipulating the tree if you want to (e.g. a setter for a | |
| 13 // 'child' property, or an 'add()' method to manipulate a list). | |
| 14 // - You can see the current parent by querying 'parent'. | |
| 15 // - You can see the current attachment state by querying | |
| 16 // 'attached'. The root of any tree that is to be considered | |
| 17 // attached should be manually attached by calling 'attach()'. | |
| 18 // Other than that, don't call 'attach()' or 'detach()'. This is | |
| 19 // all managed automatically assuming you call the 'adoptChild()' | |
| 20 // and 'dropChild()' methods appropriately. | |
| 21 // - Subclasses that have children must override 'attach()' and | |
| 22 // 'detach()' as described below. | |
| 23 // - Nodes always have a 'depth' greater than their ancestors'. | |
| 24 // There's no guarantee regarding depth between siblings. The | |
| 25 // depth of a node is used to ensure that nodes are processed in | |
| 26 // depth order. The 'depth' of a child can be more than one | |
| 27 // greater than the 'depth' of the parent, because the 'depth' | |
| 28 // values are never decreased: all that matters is that it's | |
| 29 // greater than the parent. Consider a tree with a root node A, a | |
| 30 // child B, and a grandchild C. Initially, A will have 'depth' 0, | |
| 31 // B 'depth' 1, and C 'depth' 2. If C is moved to be a child of A, | |
| 32 // sibling of B, then the numbers won't change. C's 'depth' will | |
| 33 // still be 2. This is all managed automatically assuming you call | |
| 34 // 'adoptChild()' and 'dropChild()' appropriately. | |
| 35 | 9 |
| 36 int _depth = 0; | 10 int _depth = 0; |
| 37 int get depth => _depth; | 11 int get depth => _depth; |
| 38 void redepthChild(AbstractNode child) { // internal, do not call | 12 void redepthChild(AbstractNode child) { // internal, do not call |
| 39 assert(child._attached == _attached); | 13 assert(child._attached == _attached); |
| 40 if (child._depth <= _depth) { | 14 if (child._depth <= _depth) { |
| 41 child._depth = _depth + 1; | 15 child._depth = _depth + 1; |
| 42 child.redepthChildren(); | 16 child.redepthChildren(); |
| 43 } | 17 } |
| 44 } | 18 } |
| (...skipping 32 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
| 77 void dropChild(AbstractNode child) { // only for use by subclasses | 51 void dropChild(AbstractNode child) { // only for use by subclasses |
| 78 assert(child != null); | 52 assert(child != null); |
| 79 assert(child._parent == this); | 53 assert(child._parent == this); |
| 80 assert(child.attached == attached); | 54 assert(child.attached == attached); |
| 81 child._parent = null; | 55 child._parent = null; |
| 82 if (attached) | 56 if (attached) |
| 83 child.detach(); | 57 child.detach(); |
| 84 } | 58 } |
| 85 | 59 |
| 86 } | 60 } |
| OLD | NEW |