Even though they had been moved into the
`ClassAction` module, that module still had the
potential for conflict. Instead, we'll just put
evenything in the Conversion namespace. That way
we need not worry.
It appears that `Ref::WeakValueMap` is not 100%
correct. There are cases where entries are
temporarily corrupted; probably while attached
finalizers run.
This is a slight decrease in flexibility in that
strings and primitives cannot maintain referential
integrity when passed by reference to v8, but the
default is to pass them by value anyway, and it
greatly reduces the number of object_ids that the
idmap sees and therefore reduces the chances of
a recycled object id causing a bad lookup.
While this is not a perfect fix, it does make a
collision very unlikely, and it prevents the
crashes being seen in #169
If this pops up again,
we'll have to look at getting a perfectly reliable
weakmap implementation.
When we have a JS object that proxies a Ruby
object, store a hard reference to the Ruby object
so that it cannot be garbage collected as long as
a reference is being held from within JavaScript.
It turns out that the Ruby stdlib WeakRef class is
completely broken.
http://bugs.ruby-lang.org/issues/4168
While it is fixed in trunk, it is not useable, so
as a temporary measure, use the `ref` gem as a
dependency. It appears to be both faster and more
correct.
in between the weakref_alive? check and the actual
dereference via `__getobj__` the weak reference
could have been collected. It's better to just go
ahead and do the deref. If it throws an error,
then we know it didn't work.
