"Markus" <markus / reality.com> 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