[Ironruby-core] Inheritance in IronRuby - possibly a bug or two?

Charles Strahan charles.c.strahan at gmail.com
Fri Sep 24 02:40:07 EDT 2010


I have a couple questions about deriving from C# class from IronRuby. For
context, here's a code example that I will refer to here in a bit:

========================================

using System;
using System.Reflection;
using IronRuby;
using IronRuby.Runtime;
using Microsoft.Scripting.Hosting.Providers;

namespace Example1
{
    public class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public Person(string firstName, string lastName)
        {
            FirstName = firstName;
            LastName = lastName;
        }
    }

    class Program
    {
        private static readonly string _rubyScript = @"

class Person2 < Example1::Person
  def initialize(first, last)
    super(first, last)
  end
end

Person2.new(""Foo"", ""Bar"")

";

        static void Main(string[] args)
        {
            var runtime = Ruby.CreateRuntime();
            var engine = runtime.GetEngine("rb");
            var context =
(RubyContext)HostingHelpers.GetLanguageContext(engine);
            var scope = engine.CreateScope();
            runtime.LoadAssembly(typeof(Program).Assembly);

            engine.Execute(_rubyScript, scope);

            Console.WriteLine(". . .");
            Console.ReadKey(true);
        }
    }
}


========================================


If you run that code, you'll get the following:


InvalidOperationException: can't allocate class `Person2' that derives from
type `Example1::Person' with no default constructor; define Person2#new
singleton method instead of Person2#initialize


Is this a bug, or is this intended behavior?  If this is intentional, then I
think there's still a different problem: try adding this default constructor
and then run the code:

        public Person()
        {
            Console.WriteLine("Uhmmm... what did IronRuby do with
`super(first, last)`?");
        }

So, the `super(first, last)` still get's executed... but what did it do? It
obviously didn't forward those arguments to the non-default constructor...

So, I think that means we have one, or possibly two, bugs.

Back to the first question: Wouldn't it be possible to determine the correct
constructor to invoke based on the arguments, thus avoiding the exception? I
would imagine that the generated/emitted subclass could contain all of the
same constructors that the base type has, just passing the arguments on to
the base class's corresponding constructor (I hope that made sense - sorta
tricky to word that correctly).


By the way, how should I specify that I _don't_ want the Ruby code to be
interpreted? I noticed that the debugger broke
in Microsoft.Scripting.Interpreter.Interpreter... maybe that could be part
of the problem.

Cheers,
-Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100924/a1ddd5e8/attachment-0001.html>


More information about the Ironruby-core mailing list