On Aug 15, 2006, at 11:22 AM, John Lam wrote:

> First off, I'd like to check this observation with folks on the list:
>
> VALUEs today in Ruby are (sometimes) pointers to objects, and since
> those objects don't (today) move in memory, we can assume that they
> are invariant for the lifetime of the process.
>
> If that is true today, then here's an interesting implication:
>
> In future implementations of Ruby where presumably Ruby objects will
> be managed by more sophisticated GC's which *do* move objects in
> memory when collecting, this will potentially impact the semantics of
> VALUE. What happens to existing C-based extensions which assume the
> current semantics of VALUE in a world where objects move?
>

a VALUE won't be a VALUE then anymore. I imagine the whole api would  
have to change.

> In the CLR, we have a type called a GCHandle which lets us get a
> reference to an object that can be manipulated directly by unmanaged
> code - sometimes this can even involve pinning the object in memory
> for the lifetime of the GCHandle.
>
> Are the semantics of VALUE doc'd somewhere?
>
There's README.EXT

> Thanks
> -John
> http://www.iunknown.com
>