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] Google Code Archive - Long-term storage for Google Code Project Hosting.

Cheers,
Steve

Steve E.:

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 L. (IRONRUBY)
[email protected]

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 L. (IRONRUBY)
[email protected]

Steve E.:

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