Ironruby core - Apr 2008 - System.Action name collision

Cross-posting to mono-dev and ironruby-core.

System.Action delegate types (and its generic versions) were newly
introduced in .NET 3.5, and they live inside System.Core.dll.

Dynamic Language Runtime wants to run on .NET 2.0, so it has its own
version of these simple classes as Microsoft.Scripting.Utils.Action
(and its generic versions).

Now Mono 1.9''s C# compiler defaults to C# 3.0 mode, and to quote,
"the
System.Core.dll assembly is now referenced and this might cause some
type ambiguities, in particular with the "Action" type (System.Action
from System.Core vs Gtk.Action for example). The fix is to either use
fully qualified names for Gtk.Action, or to use namespace aliases."
(See Mono release note.)

Many IronRuby source files do both "using System" and "using
Microsoft.Scripting.Utils", and name collision happens. Now Gtk.Action
is annoying, but using fully qualified
Microsoft.Scripting.Utils.Action is horrifying.

Using "using alias directive" won''t work with generics. C#
Language
Specification ECMA-334 25.5.7 specifically disallows this. This is
logged as Microsoft Connect Feedback 93520 which is closed as
"postponed" since 2004.
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93520

I can live with substituting all occurences of Action class, but I
wonder if any of you have better idea.

-- 
Seo Sanghyeon

Hey,

On 4/9/08, Sanghyeon Seo <sanxiyn at gmail.com>
wrote:
>  Now Mono 1.9''s C# compiler defaults to C# 3.0 mode, and to quote,
"the
>  System.Core.dll assembly is now referenced and this might cause some
>  type ambiguities, in particular with the "Action" type
(System.Action
>  from System.Core vs Gtk.Action for example). The fix is to either use
>  fully qualified names for Gtk.Action, or to use namespace aliases."
>  (See Mono release note.)
It''s worth noting that it''s not just a Mono issue.
You''ll have the
exact same issue as soon as you''ll compile on csc 3.5, as discussed in
a previous thread.

-- 
Jb Evain  <jb at nurv.fr>