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

Reply via email to