Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
I have not forgotten about my series on method type inference; rather, the contrary. I have been thinking hard about how to change method type inference to be more accurate in a hypothetical world with covariant and contravariant interfaces, and this has led me to dig in even deeper to the method type inference specification and implementation. I've got acres of notes on this now; getting them into bloggable form will take more time.
Until then, some of the wit and wisdom of the managed languages team.
We "dogfood" our source control system here; that is, we now use the same source control system that we sell to customers to control our own sources. Even better, we use recent builds of the source control system, so that we find the flaws in new versions of it before customers do. We feel the pain so that you don't have to. But this means that occasionally the Software Development Company Abstraction breaks down for a few hours here and there.
Some wags have started writing suggestions for what to do when the source control server is down on the whiteboard outside my office. So far, the list consists of:
0) Teach the VB team what index lists begin at.1) Send email to [the source control server team].2) Complain.3) Update this whiteboard.4) Learn helplessness.5) Go to Tosche Station. Pick up some power converters.6) Consider the management track.7) Write a new source control system -- yes, you have enough time.
What do you do when your source control / bug database / network / email / whatever crucial system is temporarily unavailable?
> in a hypothetical world with covariant and contravariant interfaces
While the C# team is tinkering with interfaces, I have a suggestion.
Recently I found myself creating an interface which would be implemented by some derived WPF Visuals. The interface adds certain properties and methods to these Visual objects. The specifics aren't really important, let's call the interface IEnhancedVisual.
Here's the thing, this interface is only designed for use on WPF Visual objects. It would be great if I could enforce that at compile time, and save a lot of run-time casts and type-checking. Right now, if I have a list of IEnhancedVisuals, I either have to dynamic-cast each one to Visual to do any WPF work on it, or declare it as a list of Visuals and dynamic-cast to IEnhancedVisual to get to the "extra" members.
Of course, there's always the risk that some fool will put a plain Visual on a list intended to be only IEnhancedVisuals. Or implement IEnhancedVisual on a random class. Even if they don't, all the casts and type-checking has to be done at run-time, often inside a foreach loop. What I really want is this:
interface IEnhancedVisual : Visual, INotifyPropertyChanged
This just restricts the interface at compile-time. Classes can only implement the interface if they inherit from Visual.
At first glance, it might look like the interface is just an abstract class, but of course it's very different. By making it an interface, you can "glue" it onto leaf nodes on the class tree. For example, you can create an EnhancedButton class which inherits from button and implements this interface. The problem with an abstract class is, you would have to "start over" at the root Visual object, and somehow reimplement all the controls you want to use.
Note that the language already does this implicitly with object:
interface IEnumerable : object
If it didn't, this code wouldn't work:
An excellent suggestion. A slightly different way to cast this feature would be to allow a related group of extension methods to form an "extension interface". Since extension methods extend a particular type, an extension interface could also be restricted to extending any type you chose and no others.
We are definitely considering more "extension" features in the future, but hypothetically speaking, we would not have any of this work planned for the hypothetical next release, if there were one, which I'm not confirming or denying. :-)
"What do you do when your source control / bug database / network / email / whatever crucial system is temporarily unavailable?"
Take a break. :)
attrib -r filename
and when back up, tfpt online filename
Ugh. tf.exe needs an option for checkout now and fix server status when it can reach the server.