Since articles on the O'Reilly Ruby Blog are supposed to fit in a certain length, there are always a couple of choice bits that need to be trimmed. I'm finishing up an interview with Charles Nutter and Thomas Enebo, the developers of JRuby, and have a couple of pieces to post here. Enjoy!
I'm not sure I understand why C Ruby having C extensions limits its ability to make "sweeping architecture changes". Is this because the API must be kept stable, or is there some other reason? Does JRuby not have Java extensions that present the same kinds of problems?
Charles: Ruby's C extensions have access to the full set of internal Ruby APIs; this means they are heavily dependent on Ruby's internal data structures, object creation mechanisms, call semantics, and so on. As a result, C extensions require that those APIs, structures, and semantics all work the same from version to version. To change them would break many extensions.
In JRuby, we have a number of libraries implemented in Java, but there are few if any third-party JRuby extensions, owing mainly to JRuby's relative youth (and our repeated discouragement from creating extensions that depend on internal APIs). We plan to support an extension mechanism (Java-based, of course), but it will be far removed from the inner workings of JRuby itself.
C Ruby is essentially an open book, where extenders can call any internal APIs or manipulate internal data structures to achieve their ends. This makes those extensions very powerful and flexible, but requires that Ruby internals be frozen.
No comments:
Post a Comment