explicit-interface

When browsing ASP.NET MVC source code in codeplex , I found it is common to have a class explicitly implementing interface. The explicitly implemented method/property then invoke another "protected virtual" method/property with same name. For example, public class MvcHandler : IHttpHandler, IRequiresSessionState { protected virtual bool IsReusable { get { return false; } } bool IHttpHandler.IsReusable { get { return IsReusable; } } } I'm now sure what's the benefit of this kind of programming. For me, I prefer to just implicitly implement the interface IHttpHandler. I guess the author just don

I have a vexing error. type Animal = abstract member Name : string type Dog (name : string) = interface Animal with member this.Name : string = name let pluto = new Dog("Pluto") let name = pluto.Name The last line, specifically "Name" generates a compiler error saying that "the field, constructor or member 'Name' is not defined". The workaround I've used is to write let name = (pluto :> Animal).Name However this is very annoying and creates a lot of visual noise. Is there something one can do in F# to just be able to resolve Name without telling the compiler explicitly that Name is a derived

My question is somewhat related to this one: How does a generic constraint prevent boxing of a value type with an implicitly implemented interface? , but different because it shouldn't need a constraint to do this because it's not generic at all. I have the code interface I { void F(); } struct C : I { void I.F() {} } static class P { static void Main() { C x; ((I)x).F(); } } The main method compiles to this: IL_0000: ldloc.0 IL_0001: box C IL_0006: callvirt instance void I::F() IL_000b: ret Why doesn't it compile to this? IL_0000: ldloca.s V_0 IL_0002: call instance void C::I.F() IL_0007: ret

I'm very new to Fortran, and for my research I need to get a monster of a model running, so I am learning as I am going along. So I'm sorry if I ask a "stupid" question. I'm trying to compile (Mac OSX, from the command line) and I've already managed to solve a few things, but now I've come across something I am not sure how to fix. I think I get the idea behind the error, but again, not sure how to fix. The model is huge, so I will only post the code sections that I think are relevant (though I could be wrong). I have a file with several subroutines, that starts with: !========================

The other day i was looking at C# Boolean struct metadata. Boolean implements the interface IConvertible. But looking at Boolean's members i could not see most of the IConvertible members. I've done some tests with some colleagues, including creating our own classes, and came to the conclusion that IConvertible must be implemented explicitly for Boolean. The question is, why are they not visible? I understand it might be a 'by design decision' but i understand that it would add greater value if they were visible to anyone inspecting the metadata. The tests were done in VS2010 .NET4.0 The

I am getting a compile error from the following property. The error is: "The modifier 'public' is not valid for this item" public System.Collections.Specialized.StringDictionary IWorkItemControl.Properties { get { return properties; } set { properties = value; } } but if I remove the IWorkItemControl it compiles fine. Why am I getting this error and what is the difference of having / not having the interface name in the signature? Explicit interface implementation does not let you specify any access modifiers. When you implement an interface member explicitly (by specifying the interface name

I was using the FtpWebResponse class and didn't see a Dispose method. It turns out that the class implements IDisposable, but does so explicitly so that you must first cast your instance to IDisposable before calling Dispose: // response is an instance of FtpWebResposne ((IDisposable) response).Dispose(); Why would the designer of a class such as this one choose to implement IDisposable explicitly? As Anthony Pegram says , doing things this way masks the fact that the object should be disposed for the average developer who is not consulting the documentation every time he/she uses a class.