From: Robert Klemme Date: 2004-10-27T00:54:05+09:00 Subject: Re: How to bind a graph structure? "Markus" schrieb im Newsbeitrag news:1098804673.21256.734.camel@lapdog.reality.com... > On Tue, 2004-10-26 at 02:14, Erwan Loisant wrote: > > What could be a better design? I there a way to design my C library > > better so I can tell Ruby's garbage collector about references without > > introducing a Ruby dependency in my library's source code ? > > I'm not sure that this is logically possible to do in a clean way. > You may be able to find a way to do it with no _explicit_ dependencies > on Ruby in your source code (though I don't see how), but only by > introducing some _implicit_ dependencies, e.g. relying on side effects > of the interaction between your code & ruby's to do what you want. This > would be very brittle. IMHO this is the typical situation of layering object models: the Ruby object model (the wrapper instances) sits on top of the C object model and each Ruby model instance refers to at most one C model instance. The hard part with this scenario is, as both of you noticed, to deal with object construction and even more so object destruction. > One idea might be to give ruby "handles" of some sort that were > only usable/meaningful via calls to your library. As far as ruby's GC > was concerned, they would just be integers. You would then be able to > manage your storage as you saw fit, and ruby would be able to do > likewise. IMHO this is probably the most reasonable approach. Additionally Erwan should then have some mechanism of verifying the handle stored in a wrapper object to be able to detect the situation that you have a wrapper whose corresponding C model instance is gone. Unfortunately you would have to check the validity in every method that needs the C model instance or even in *every* method. Alternatively you need some kind of observer mechanism so your Ruby model instances get to know that their C model counterparts are gone. But even then you still some other object might reference the Ruby model instance... Another issue is aliasing: depending on the application it might be crucial that you have at most one Ruby model instance per C model instance, i.e., you want the same representant on the higher level. This is typically the case when you store additional state in the wrapper instance. You can handle this with some sort of mapping - but you'll have to be careful with respect to GC in order to not fix wrapper instances in mem: You might need a Hash where values are WeakReferences to the wrapping instances. This is all not very nice and personally I haven't found a clean, nice and efficient solution to this issue... Kind regards robert