Note: this list of a bit outdated; basically a snap-shot of IronRuby's roadmap late in 2009. New roadmap will be posted when 1.8.7, 1.9, and IDE support planning starts.

Here are the features IronRuby is tracking on its way to declaring "1.0". “P1” features are needed in 1.0, “P2” features are still very important, but subject to change, and “P3” features are nice to have, but IronRuby can ship without them.

IronRuby.dll

Core

[P1] Perf: 2x+ better than MRI, on par with JRuby

~~[P1] Sites: need to be runtime independent to improve performance of Ruby events/notifications (eg. method_added).~~

~~[P1] Interpreter: DLR tree or continuation-passing style interpreter?~~

~~[P1] Regex: Regular Expression engine performance optimization. Current engine is a wrapper around .NET regex.~~

~~[P2] Binder Initializers: work needed for better supporting Ruby semantics. There may be CLR interop issues with this approach, so need to investigate.~~

~~[P2] Stack traces: currently stack traces are not the same as Ruby. Interpreter may make this easier to do~~

~~[P2] CLS visibility: See CLS methods/properties on Ruby objects after doing require 'mscorlib'~~

[P3] Scope optimizations: This work should merge RubyScope and RFC, disable eval aliasing -> no dictionaries. This is mainly for throughput optimization; makes IronRuby look better on micro-benchmarks, but it may not affect most scenarios. Need to investigate.

~~[P3] Block-call optimization: Mostly a cleanup of BlockParam (instance_eval, module_eval, super). Enables super and those special-type of methods in eval.~~

[P3] Binder - Port RubyMethodGroup to MetaObjects: This can help improve error messages (ie. ruby-compatible error messages, which get the type of exception correct). This might require some DLR refactoring. MetaObjects is mainly for DLR language interop, so this can wait.

[P3] Binder – Failures caching that do not throw exceptions: This is mainly for DLR language interop, as MetaObjects excepts a fall-back strategy, and IronRuby just throws. The optimizations that arise from this could also be covered by the Sites work.

~~[P3] Thread safetey - Also needs DLR work (eg. Scope)~~

~~[P?] Language features - BEGIN/END~~

.NET Interop

[P1] Support well-known .NET interfaces (both ways are needed, but Ruby calling C# is more baked): Data Binding, IEnumerable <-> Enumerable mixin, IComparable <-> each, etc (see .NET Test Plan’s “Special Concepts”).

[P1] IDynamicObject support - Conversions to .NET types, Operator support

~~[P1] to_s -> ToString on non-library CLR classes (including enums), GetHashCode (CLR calling Ruby is simple, both directions should be supported)~~

~~[P1] Accessing protected methods, accessing public overrides on internal types~~

~~[P1] Constructors: Control which constructor to call when deriving from a CLR-type. Today it just calls the default constructor.~~

[P1] Operators - op_Addition maps to + (Ruby calling CLR should use DLR + operator which maps to op_Addition), enums

~~[P2] Type Builder: Move it to the DLR, but Ruby needs a base implementation. If this is shared among languages, this can give IronRuby compilation support.~~

~~[P3] COM: for Win32OLE compatibility~~

[P3] Explicit Interface implementation

[P3] Non-default indexers

~~[P3] Overriding generic Methods.~~

[P3] Hashing equality

[P3] Access to internal and private members: This is useful for testing since InternalsVisibleToAttribute cannot be used to give access to Ruby scripts. It can be a command line switch like -X:PrivateBinding

IronRuby.Libraries.dll

Libraries are more straight-forward to implement than the core because of RubySpec, and the library support will be scenario-focused (ie. what libraries are needed to run rails, merb, gem, rake, etc). Here are the libraries which are known to need work:

MutableString basic operations - $KCODE and encodings are TODO

~~IO, files, FileTest, streams, sockets~~

Cryptography: OpenSSL, Digest

String: formatting, unpack/pack

Encodings: iconv, String methods

Signals: Ctlr+C

Process

ARGF: InputProvider

Time

Builtins freezing (array, hash)