Ruby Forum IronRuby > generic and non generic type with the same name

IronRuby seems to be having a problem resolving a generic type when a 
non
generic type with the same name exists.  The specific example that I
discovered the bug with is when trying to using Moq [1].

describe "some class with a mock" do
  it "should use the mock" do
    mock = Mock.of(IMyMock).new
    my_class = MyClass.new(mock)
    // ... test stuff
  end
end

Moq has a generic and non generic version of the Mock class.  When I try 
and
run the code above it tells me that Moq.Mock is not a generic type. 
After
digging through the code a bit it looks like this should be handled my
Microsoft.Scripting.Action.TypeGroup.  I haven't been able to uncover 
where
IronRuby makes use of this as of yet.  Is this a known bug, or should I
submit a bug on rubyforge...or am I doing something wrong?

[1] http://code.google.com/p/moq/

Cheers,
Steve

Steve Eichert:

> end
Yep. Sorry. That's a bug. Can you open a bug please?

We more or less hacked in whatever 'support' that we needed to get basic 
generics up and running so that we could do some Silverlight/WPF stuff. 
It was almost entirely on the side of consuming generic types, and this 
case didn't come up.

As for the timeline for fixes around this stuff - it will happen 
post-RailsConf when we refocus on getting our .NET interop story 
correct. Right now we have our hands full trying to get the core 
language up and running.

Thanks!
-John

This issue has been reported on Rubyforge (bug #20033).

Can you point me in the general direction of where things would need to
change in order to get this to work so I can hack around a bit?

Cheers,
Steve

On Thu, May 8, 2008 at 9:56 AM, John Lam (IRONRUBY) 
<jflam@microsoft.com>

Steve Eichert:

> This issue has been reported on Rubyforge (bug #20033).

Thanks!

> Can you point me in the general direction of where things would need
> to change in order to get this to work so I can hack around a bit?

The high order bit here is that we're not delegating to the default DLR 
binder in our implementation as much as we will in the future. A lot of 
those features already exist in the DLR binder, so it's really a matter 
of making that happen.

That said, our binder is going to undergo some major work post 
RailsConf.

FYI - although you're more than welcome to hack around and even create 
patches that others can apply to their own private builds, we cannot 
accept patches in the core IronRuby compiler today -- libraries are the 
only place where we generally accept patches. Trivial patches for bug 
fixes are excepted from the 'no patches to IronRuby core' policy. This 
is why we have the distinction between IronRuby.dll vs. 
IronRuby.Libraries.dll

Thanks,
-John

My goal was mostly to hack around and try and get it working with the
assumption that you guys would do it the right way sometime after 
Railsconf
and I would throw my hack out.

I'll dig around in the Binder to see if I can uncover anything.

Thanks,
Steve

On Thu, May 8, 2008 at 11:22 AM, John Lam (IRONRUBY) 
<jflam@microsoft.com>