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.

Java does this kind of stuff well, I believe.

Eric Shaneson
Cutting Edge Consulting
>Eric,
>
>You are not butting in at all.
>
>>I think reference counting is a HUGE plus and fairly mandatory to a good OOP language. I don't know how you would get by without it. The only problems I've ever encountered are when my classes are not well encapsulated and have dependencies on other objects that they are not responsible for and just expect to exist. I've learned (through some trial and error) that this is always bad design.
>
>I too hate to design with a requirement that some external object exist. I usually end up coding a UDF that will first look to see if it's out there and return a reference, otherwise it instantiates it. I definately minimize this type of thing though, but at some point a framework becomes complex enough that it's hard to avoid it.
>
>>Objects should always instantiate and release all resources that they require. I can't think of a properly designed example where I would want to release the resources of an object that was in scope somewhere else. I would, however, want all of those resources to be release when the object was no longer in scope ANYWHERE. The goServer example from earlier in the thread is the best example. Why would I want to be coding in each client for the existence of goServer? And then, if it's not there and I need it I'll probably have to re-instantiate it, with every one probably ending up with their own copy of the object afterwards.
>
>That's why I use a singleton pattern with a UDF to seek out the server and instantiate it if it's not there already. I use a UDF precisely to avoid duplicated code inside class methods.
>
>>The References[] collection is a better idea, in my opinion, if such a thing is possible. From what I understand about the way reference counting mechanisms work it would be difficult.
>
>The backwards pointers to the references are fraught with perils of their own *s*
>
>And the worst problem I had was in a classlib parser that created several double linked lists of nodes. There was just no way to ever get everything to properly release. I had to create a single linked list of allocated nodes in the lowest level node class that provided a way to get to every node so that they could set their pointers .null.