Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
>
....
> >
> > Passing foreign objects directly via the FFI does not have this
> > problem, because there is a special lifetime guarantee for this
> > kind of values. :-P
>
> Actually, doesn't that prove the point that I tried to make
> when we discussed this previously, namely that the "special
> lifetime guarantee" isn't a very good idea in the first
> place? It's a kludge. As soon as a ForeignObj is not
> passed as an explicit argument to a C function, but as part
> of a compound data structure, the kludge breaks.
>
> As SimonM said in a previous email (and Michael Weber
> pointed out in our earlier discussion), if you pass a
> ForeignObj to C and want to be sure that it doesn't get
> finalised, you have to StablePtr it. Why should there be a
> difference between the case where the ForeignObj is passed
> as an individual argument and the case where it is passed as
> part of a compound structure?
>
Because the latter you have control of how it is marshalled
(it is not a prim type), while the former you don't. Call it
a kludge if you wish, but I prefer the FFI to be safe.
> The only excuse that I see at the moment is that the special
> lifetime guarantee saves some typing in the common case -
> not a very good excuse for an awkward language feature,
> I think. Especially, as we can handle this case also nicely
> in the FFI marshaling library (by providing a wrapper that
> does the `StablePtr'ing).
>
So, you're saying that if you've got an object reference to
some external (CORBA?) object, you want to allocate a StablePtr
everytime you pass it out & de-allocate it upon return? Sounds
a bit OTT to me.
--sigbjorn