Eric,

Having an oChildObject_Access method like that is a cool idea. It allows things like rarely used decorators, for example an oContextMenu, to just be added at the moment of use.

There was another place where having the single linked list (SLL) of allocated nodes was necessary. With complex graphs it was easy to hit the recursion depth limit. The processing the SLL in order allowed all the other links to be removed in a linear routine.

>I've been doing this king of stuff with Access/Assign in VFP. In order to reduce dependencies, when I have an object that requires some other object that might be shared, I create a property and add an Access method to instantiate the object when it might not be there. For example:
>
>DEFINE CLASS MyObject AS Custom
> oChildObject=.NULL.
>
> FUNCTION setChildObject
> LPARAMETERS oObject
> IF VARTYPE(oObject)#"O"
> oObject=NEWOBJECT("MyClass","MyLibrary")
> ENDIF
> this.oChildObject=oObject
> RETURN
> ENDFUNC
>
> FUNCTION oChildObject_Access
> IF VARTYPE(this.oChildObject)#"O"
> this.setChildObject()
> ENDIF
> ENDFUNC
>ENDDEFINE
>
>A simple example, of course, but this way I can either call setChildObject externally, have it created if I create the class independently, or set it at any point later that I feel like with a different copy of the object. I could even write the Access method to check for an existing store if I felt like it.
>
>This is a very Set/Get - like approach. I'm not sure what the name of the OOP construct is. Of course, this can be tricky with extremely stateful objects where I always need a SPECIFIC copy of an object with SPECIFIC property values, but I try to avoid that type of situation wherever possible. I'd rather have the class stand on it's own as much as possible.
>
>The node example you explain below is a tough one. I also end up with singly linked lists that know their parents so you can walk the tree. To do what you are talking about you'd need to write some sort of HashTable-like mechanism, I think, and store children and parent keys there.