The currently supplied Date mapping is far from ideal... but it's a start, and at least shows the most basic intended use of the conversion/ wrapper APIs.
(to match its new location, per my earlier change to Rakefile)
This allows pure-ruby code to control how different JS values are presented to the rest of ruby-land. Such wrappers provide for the most common case, but there's also a need to be able to define a conversion to be applied each time the proxy is required, too. And then we need corresponding functionality in js-land.
Similarly, invent a J::RubyLandProxy, which is the superclass of J::SM::RubyLandProxy. Neither of these classes are useful in themselves, without an engine-specific subclass providing the real implementation... but their separate existence should simplify documenting the user-relevant API.
Also, be a bit more careful about what we let through; it doesn't have to be an Array, but it does have to be convincingly array-like.
Not really adding a lot of real information... and I think I've made a mess of the call-seq presentation.
ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
I suspect there are still more; I haven't done a complete read-through with my new appreciation of everything that can cause problems.
Seems to prevent a BOM occassionally showing up somewhere... there's probably a better way to deal with that?
This isn't *quite* true, because ECMA says strings can contain unmatched surrogates... but it should substantially improve our behaviour for more "normal" situations.
These were mostly found by inserting a random chance for an exception into some of the conversion functions.
In the process, fix Array#length to be a JS property, too.
This is better than trying to keep the runtime alive longer than the proxies, because that breaks down during interpreter shutdown -- as evidenced by the complaints that were appearing as soon as we had a failing test, and upon an Interrupt.
By storing a reference to the runtime in a long-lived location while there are live proxies, we can ensure the proxies will be collected first. Otherwise, when the whole proxy+runtime chain becomes unreachable, they could be collected in any order... and having the runtime go away while we still have proxies around makes SpiderMonkey quite upset.