Anyone who has read about
Ruby may have heard about
Duck Typing;
it allows any object to be passed into a method as long as the object
has the properties/methods used by the originating method. If this were
to be implemented in C# it would look something like:
public void Blah(object foo)
{
Console.WriteLine(foo.Bar);
Console.WriteLine(foo.Kung("Jackie Chan"));
}
And
it would work completely fine at run-time as long as the object passed
to the Blah method had a property called "Bar" and a method called
"Kung" that took in a string as an argument. Unfortunately this won't
work in C# because C# is a strongly typed language, "object" simply
does not have a "Bar" property, nor a "Kung" method. Strong typing does
have its advantages though, IntelliSense and compile time checking. If
in Ruby you were to call the Blah method and it didn't have the
appropriate properties and methods you would receive a run-time error.
Run-time errors are bad because they make end-users cranky, which makes
your boss cranky, which makes you cranky.
Strongly typed
languages can have some of the benefits of this flexibility with
Interfaces. Just create an IFoo interface with the needed properties
and you're off to the races, right? Well, yeah, but only on objects
that you have the ability to edit, which leaves you praying that the
authors of your dependencies have your
bizarre perfectly reasonable needs in mind (not likely).
For
instance, I recently wrote a windows component that would listen for
some events on a textbox and process the results. The only problem is I
wanted to let the user hook up the component to either a TextBox or a
ToolStripTextBox. Since those objects don't share a common interface, I
have to have two separate properties on the component, a TextBox and a
ToolStripTextBox and at run-time I have to throw an error if the user
assigned a value to both properties (and remember, run-time error !=
desirable).
What I propose is the natural extension (pun intended) of
Extension Methods
-> Retroactive Interfaces. Simply put, I'd like to be able to tell
the compiler that certain classes implement an interface, but do so
from the interface, not from the class (because I may not be able to
edit the class). I don't really care what the exact syntax is but I
could imagine it going something like:
using System.Windows.Forms;
public Interface IText ImplementedBy TextBox, ToolStripTextBox
{
string Text { get; set; }
event EventHandler TextChanged;
}
This
is if you wanted to be fairly precise about which classes implemented
your new interface, but it would be also nice if to tell the compiler
that you wanted any object that has the appropriate
properties/methods/events to have it implement said interface. Such
syntax could look like:
public Interface IText ImplementedByAllAppropriate { ... }
And voilà, you now have the flexibility of Duck
Typing and the compile time checking and IntelliSense of Strong Typing.
I know bureaucracy can be a wildly beast, so
Anders,
if you're reading, I'm willing to grease proverbial wheels with
$2,000,000 to get this feature in the next version of C#. (No, I don't
have the $2,000,000 right now, but I'm working out a very lucrative
deal with a rich Nigerian General)
Post Script: Like Extension Methods, Retroactive Interfaces aren't aimed at solving some unsolvable problem. You can definitely use the
Adapter Pattern
to wrap up the object and have the adapter class implement the needed
interface. But lets be honest, its simply a pain in the ass, it takes
time to write the adapter class and you have to explicitly create an
adapter for every class you want to implement your interface
(ImplementedByAllAppropriate, isn't really possible with an adapter). A
Retroactive Interface is some syntatic sugar aimed at making developers
lives easier.