in reply to recursive creation of attached objects?
Usually, I define the constructor to create an empty, pristine object in its default virginal state, and then I define a second method, say init(), or in this case maybe a property such as depth or a function set_depth(), which is called immediately thereafter. Sometimes, several related objects are created, then their respective initialization-routines are called in some prescribed sequence.
The main reason for this is that, once the constructor has finished, whatever variable you are using to store the location of the object in your application, now has a non-undef value ... as it will throughout the remainder of the execution of the program. If your various objects routinely interact with one another by referencing some kind of global variable set, they can rely upon all of those variables being populated and that the referenced objects exist. Now, only the constructors are “the odd man out,” unable to rely upon anything other than itself. Even though in a “purist” sense these sort of things ought not to matter, in my experience no actual software implementation is really that “purist.” Anyway, it works well for me.
Furthermore ... even though right now you want the initial state of the object to be “five levels deep,” is that really guaranteed for all time to remain just-so? If you “wedge” the code to establish tree-depth into the constructor, you might one day regret having done that. It isn’t good to box yourself in.
Also... Sometimes you can create an object that maintains a “sparse” data structure that always appears to be “five levels deep,” but that only stores what is necessary; e.g. what is different from the known default. The clients of the object would never know or care. If you’re stipulating a five-level depth because you know to anticipate this as your final-state and you don’t want to burn time on tree-rebalancing, that’s fine too.