Array experiments #9055
Array experiments #9055
Conversation
cf09b04 to
e8e1639
Compare
|
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 I believe only the following forms are public:
These are basically in order of risk, with the sized 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 |
2819431 to
d74cb7a
Compare
|
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. |
d74cb7a to
2e5b6a5
Compare
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.
2e5b6a5 to
956b746
Compare
This PR will encompass some experiments with the implementation of Array: