Array experiments - #9055
Conversation
Sorry, something went wrong.
|
The abstract work is proceeding; I have been force-pushing as I find broken ends of my refactoring. I have tried to preserve as much of the public API of RubyArray as possible, even leaving most of the deprecated methods in place (they are apparently used by many of our extensions!) One area that is impossible to maintain is constructors, since they cannot be callable against an abstract class. I believe only the following forms are public:
These are basically in order of risk, with the sized (Ruby, int) form being the most likely to be used in the wild. The risk here is small, because these are peculiar forms and we have generally discouraged direct construction of core classes, but if some code out there does use these constructors there's no way to support that usage. The external code would have to be updated to use one of our factory methods. Other risks largely revolve around any code that expects getClass() to be org.jruby.RubyArray, as I found in a few of our own tests, but this is less likely to be found in the wild. |
Sorry, something went wrong.
|
I believe I have the abstractification green now with a minimal diff (outside of RubyArray.java). The remaining diffs are largely internal cases where we work directly with the "native" implementation from other core classes, such as to construct an uninitialized array for immediate population. These could be replaced with alternative forms. The risks are outlined in my comment above, and mostly revolve around the irreplaceable constructor forms. |
Sorry, something went wrong.
RubyArray will be split into RubyArray (abstract) and RubyArrayNative (concrete) to support alternative implementations. This commit makes the first stage a move, so that history can be more easily tracked.
This is a first stab at making RubyArray an abstract class, which will allow us to represent many different storage strategies as Array as seen from Ruby code: * The standard implementation, based on the CRuby logic, uses a native Java IRubyObject[] and supports full mutability and CoW sharing of that array. * Two specialized implementations extend from this and provide one- and two-element versions of Array without an IRubyObject[] field. Making RubyArray itself abstract will make it easier to add more specializations. * There are many useful collections provided by the JDK that could be used to implement Array. This change will allow them all to appear as the same Ruby type but with custom behaviors for specific use cases. * This will make for an easier path to thread-safe Array, since we can have specialized implementations that all look like Array. This is very much a prototype. I have tried to limit the changes throughout the codebase by making RubyArray abstract rather than introducing a new supertype (which would have to propagate through all RubyArray signatures in the system). The goal is to keep all RubyArray-consuming code the same as it is today while providing multiple backend implementations.
|
After discussion with @enebo, we're going to go forward with this. JRuby 10.1 will no longer allow direct construction of RubyArray and users will have to move to one of the many factory methods in that class or in org.jruby.api.Create. Full speed ahead! |
Sorry, something went wrong.
This PR will encompass some experiments with the implementation of Array: