Interface definition for static methods

[Steven Livingstone]

Anyone able to explain to me why you cannot define an interface that can
then be implemented using static methods?

I understand the C# CLS states this, but just interested in the reasons
behind it.

thanks,
Steven

 

[John Wood]

You mean *implement* the methods of an interface with a static modifier?
Obviously the signature has to match. Or perhaps you mean having statics as
part of the interface definition?

Either way, interfaces are about defining a contract of method names that an
*instance* has to support, statics aren't instance level methods they're
class level.

 

[Steven Livingstone]

Right. Static methods can't be part of the interface definition though. Any
reason?

If i write a data layer (as i am doing...) it would be nice to define an
interface that my class can then implement using static methods, rather than
instance methods.

 

[John Wood]

So even if you could put static members in an interface and implement, how
would that be useful?

Are you going to be passing around the Type of the class, and somehow you'd
expect to be able to cast that type to an interface?

Seems a bit odd.

 

[Steven Livingstone]

Well, for a start it would make sure that the variosu data providers i have
to write all conform to a specific interface. Is that odd? I would have
though that would be pretty normal. The Data Application Blocks from MS
implement their entire data layer using static methods. I'm sure if i wanted
to write for a provider other than SqlServer I would like to just tell the
implementer to implement according to *this* interface. Would help a lot at
design time.

As for the runtime behaviour, don't expect to be able to cast anything, more
that i could do something like IData.MyStaticMethod(). I don't know that
this is so odd either. Many data layer class are implemented statically and
it would be nice to able to have some reliable interface to make sure the
static method i want to call exists!

 

[John Wood]

As for the runtime behaviour, don't expect to be able to cast anything,
more

that i could do something like IData.MyStaticMethod(). I don't know that

But when you do IData.MyStaticMethod(), which class would it be referring
to??

I can understand that you may want to provide a good way to ensure that a
class provides a specific set of static members, but other than that I can't
see the use. You could possibly implement that type of validation using a
custom attribute.

 

[Steven Livingstone]

But when you do IData.MyStaticMethod(), which class would it be referring

to??

Hey, it's a Sunday, i'm not on 100% today Imagining it were possible....
I may use a helper class to return a pointer to the class containing the
static/shared methods (much as i do with instance methods for just now),
except i cache instance classes for the current user (which i wouldn't for
statics obviously). So then you have your class which implements your
interface and you can call the static methods on it as always.

There is some interesting discussion on these subjects here
http://www.mail-archive.com/[email protected]/msg00261.html

 

[John Wood]

Yeah that's an interesting idea (extending it to constructors). You could
extend the interface syntax to support constructors quite easily, eg.

interface IPlugin
{
this();
void RunPlug();
...
}

Personally I'd see that as more useful and easier for the C# compiler team
to implement than interfaces supporting static members.

 

[Jon Skeet]

Yeah that's an interesting idea (extending it to constructors). You could
extend the interface syntax to support constructors quite easily, eg.

interface IPlugin
{
this();
void RunPlug();
...
}

Personally I'd see that as more useful and easier for the C# compiler team
to implement than interfaces supporting static members.

It's much the same thing, I'd have thought.

The slightly strange thing is that as far as the CLR is concerned, an
interface *can* have static members.

I think it would be a bad idea to change the syntax to support one of
the two, but not the other - the reasons for including them are
basically the same.