On Fri, 27 Jan 2023 22:01:46 GMT, John Hendrikx wrote:
> Can this not be done in a way that doesn't require this `underInitialization`
> flag?
That's a good idea, and a also a good observation that the constructor only
really sets `treeVisible` to `true`.
I've updated the PR accordingly,
On Fri, 26 Aug 2022 00:22:54 GMT, Michael Strauß wrote:
> It's true that `Parent.getChildren()` must not return `null`, and that we
> shouldn't add null checks to protect against bugs.
>
> However, in this specific instance, `Node.setTreeVisible` is called from the
> constructor of `Node`. At
On Thu, 25 Aug 2022 22:18:44 GMT, Michael Strauß wrote:
>> `Node` adds InvalidationListeners to its parent's `disabled` and
>> `treeVisible` properties and calls its own `updateDisabled()` and
>> `updateTreeVisible(boolean)` methods when the property values change.
>>
>> These listeners are
On Fri, 26 Aug 2022 03:43:49 GMT, Nir Lisker wrote:
> I haven't looked at the code yet, but in general it's not considered a good
> idea to expose an object before it's instantiated. Not sure if we have a
> choice here though.
I agree, that's why the `underConstruction` flag is used to
On Thu, 25 Aug 2022 22:18:44 GMT, Michael Strauß wrote:
>> `Node` adds InvalidationListeners to its parent's `disabled` and
>> `treeVisible` properties and calls its own `updateDisabled()` and
>> `updateTreeVisible(boolean)` methods when the property values change.
>>
>> These listeners are
On Thu, 25 Aug 2022 22:18:44 GMT, Michael Strauß wrote:
>> `Node` adds InvalidationListeners to its parent's `disabled` and
>> `treeVisible` properties and calls its own `updateDisabled()` and
>> `updateTreeVisible(boolean)` methods when the property values change.
>>
>> These listeners are
> `Node` adds InvalidationListeners to its parent's `disabled` and
> `treeVisible` properties and calls its own `updateDisabled()` and
> `updateTreeVisible(boolean)` methods when the property values change.
>
> These listeners are not required, since `Node` can easily call the
>
