3 ms·

> "so there's nothing technically wrong with it, your objection is purely fear based; keep tabs on that fear and let me know how it goes" Wow, that seems quite

by konradb 11y ago

> "so there's nothing technically wrong with it, your objection is purely fear based; keep tabs on that fear and let me know how it goes" Wow, that seems quite patronising on the face of it, are they interacting in this way to get you to keep your distance? > "shaking the tree" with every code commit Out of interest what do you mean?

JoeAltmaier 11y ago
I'm guessing it means, with a finely-sliced tree of classes changes to any class usually changes the others in the tree. Changes are chased up and down the tree. E.g. adding a new parameter to a Read() method may require refactoring APIs at all levels.
falcolas 11y ago
> Out of interest what do you mean? "Shaking the tree" in this context means re-building the entire inheritence model when a new object is added to the tree. Any time the new object is not a leaf node, or it requires behavior from two non-direct ancestors, the inheritance tree must be "shaken" to re-order the inheritance such that the new node gets the behaviors as its ancestors, while avoiding things like diamond inheritance. The (overly simplistic) example is placing the platypus in the inheritance tree to account for its characteristics in common with two otherwise distinct parent classes (birds/reptiles & mammals).
gknoy 11y ago
I interpreted "shaking the tree" to refer to how sometimes, when shaking a small tree, you end up with more things falling out than you expected. I suspect they mean that changes which one might expect to be small and well-contained end up requiring touching your class (to add a parameter), your superclass, your superclass's superclass, and then all of the tests that depend on the superclass being a certain shape. I know I've encountered this, in several projects, so I'm not sure if it's a product of poor design (possible, I wrote some of them! ;)), or merely a side effect of a complex system. I know that lately with React, I've been having similar issues when composing things (and adding new features), so that I can pass callbacks far enough down, so it's definitely not solely related to inheritance.
- falcolas 11y ago
  Yup, it occurs any time you have a strictly hierarchical relationship between objects. Module imports, classic inheritance, display containers... all suffer from this potential problem. There's nothing technically wrong with them, and so long as you have the time to add new behaviors at the correct level and re-order the hierarchy accordingly, everything goes swimmingly. The problems arise when deadlines loom and you don't have time to identify the proper location in the hierarchy for a behavior (let alone code it), or when new members of the team don't have the knowledge of the code base to identify the proper location, or when the codebase gets too large for any single person to know where the "best" place is for something to exist... It boils down to a human problem. And since all of our developers are humans...

by konradb 11y ago

JoeAltmaier 11y ago

I'm guessing it means, with a finely-sliced tree of classes changes to any class usually changes the others in the tree. Changes are chased up and down the tree. E.g. adding a new parameter to a Read() method may require refactoring APIs at all levels.

falcolas 11y ago

> Out of interest what do you mean? "Shaking the tree" in this context means re-building the entire inheritence model when a new object is added to the tree. Any time the new object is not a leaf node, or it requires behavior from two non-direct ancestors, the inheritance tree must be "shaken" to re-order the inheritance such that the new node gets the behaviors as its ancestors, while avoiding things like diamond inheritance. The (overly simplistic) example is placing the platypus in the inheritance tree to account for its characteristics in common with two otherwise distinct parent classes (birds/reptiles & mammals).

gknoy 11y ago

I interpreted "shaking the tree" to refer to how sometimes, when shaking a small tree, you end up with more things falling out than you expected. I suspect they mean that changes which one might expect to be small and well-contained end up requiring touching your class (to add a parameter), your superclass, your superclass's superclass, and then all of the tests that depend on the superclass being a certain shape. I know I've encountered this, in several projects, so I'm not sure if it's a product of poor design (possible, I wrote some of them! ;)), or merely a side effect of a complex system. I know that lately with React, I've been having similar issues when composing things (and adding new features), so that I can pass callbacks far enough down, so it's definitely not solely related to inheritance.

falcolas 11y ago
Yup, it occurs any time you have a strictly hierarchical relationship between objects. Module imports, classic inheritance, display containers... all suffer from this potential problem. There's nothing technically wrong with them, and so long as you have the time to add new behaviors at the correct level and re-order the hierarchy accordingly, everything goes swimmingly. The problems arise when deadlines loom and you don't have time to identify the proper location in the hierarchy for a behavior (let alone code it), or when new members of the team don't have the knowledge of the code base to identify the proper location, or when the codebase gets too large for any single person to know where the "best" place is for something to exist... It boils down to a human problem. And since all of our developers are humans...