Ironruby core - May 2008 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080508/68d987bb/attachment.html>

Steve Eichert:
> 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
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 at
microsoft.com>
wrote:
> Steve Eichert:
>
> > 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
>
> 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
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080508/862d8b92/attachment.html>

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 at
microsoft.com>
wrote:
> 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
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080508/ef2ccfbe/attachment.html>