Why can't a static member be abstract or an override?

[Owen Blacker]

Ok, dumb question, I know, but I just can't get my head round it.

I'm writing a base validator class, let's call it abstract BaseFoo.
I'm also writing two implementation classes, let's call them Bar and
Quux. I want them all to share a static field that defines a regular
expression pattern used in the validation. I fail to understand why,
logically, this cannot be so. (I'm entirely willing to accept (albeit
rather frustrated) that C# just doesn't allow it, it's the *rationale*
I'm having trouble getting my head round.)

Why can I not have something like:

public abstract class BaseFoo
{
public static abstract string MatchPattern { get; }
}

public class Bar : BaseFoo
{
public static override string MatchPattern { get { ... } }
}

etc?

I read a post on a Java forum[1] that almost got my head around it,
but now I no longer follow.

Sure, the static member in the abstract class would belong to that
class and not to the derived classes. But if it's abstract (rather
than virtual, though I think the logic would still stand for static
virtual members), what difference does it make?

Surely it makes more sense, in my example, for the MatchPattern --
which will not vary between instances of the Bar and Quux
implementations -- to be static, rather than to have to declare an
instance of Bar in order to reference its match pattern?

Anyone got any explanations that will make it all make sense to me?

Anyone got any cunning ploys that will allow me to have what is
effectively an abstract static member (and overridden static members
in the derived classes)?

All responses gratefully received,


Owen Blacker,
Technical Team Lead

 

[Chris Shepherd]

Sure, the static member in the abstract class would belong to that
class and not to the derived classes. But if it's abstract (rather
than virtual, though I think the logic would still stand for static
virtual members), what difference does it make?

Surely it makes more sense, in my example, for the MatchPattern --
which will not vary between instances of the Bar and Quux
implementations -- to be static, rather than to have to declare an
instance of Bar in order to reference its match pattern?

Anyone got any explanations that will make it all make sense to me?

Anyone got any cunning ploys that will allow me to have what is
effectively an abstract static member (and overridden static members
in the derived classes)?

All responses gratefully received,

You can do something like:

public abstract class BaseFoo
{
public static string MatchPattern { get { return ""; } }
}

public class Bar : BaseFoo
{
public static new string MatchPattern
{
get { return "[A-Za-z0-9]+"; }
}
}

It's not like you have an object that you can cast to a base class in this
instance. Virtual/abstract/override are for instance members, and static
properties aren't instances. You have to know the name of the class to access
the property.

At least, that's my understanding of it.

Chris.

 

[parez]

Sure, the static member in the abstract class would belong to that
class and not to the derived classes. But if it's abstract (rather
than virtual, though I think the logic would still stand for static
virtual members), what difference does it make?

Surely it makes more sense, in my example, for the MatchPattern --
which will not vary between instances of the Bar and Quux
implementations -- to be static, rather than to have to declare an
instance of Bar in order to reference its match pattern?

Anyone got any explanations that will make it all make sense to me?

Anyone got any cunning ploys that will allow me to have what is
effectively an abstract static member (and overridden static members
in the derived classes)?

All responses gratefully received,

You can do something like:

public abstract class BaseFoo
{
public static string MatchPattern { get { return ""; } }

}

public class Bar : BaseFoo
{
public static new string MatchPattern
{
get { return "[A-Za-z0-9]+"; }
}

}

It's not like you have an object that you can cast to a base class in this
instance. Virtual/abstract/override are for instance members, and static
properties aren't instances. You have to know the name of the class to access
the property.

At least, that's my understanding of it.

Chris.

Heres two post i found online.. that makes sense to me..

--------
An abstract method requires implementation per instance. Static
methods pertain to an overall class. A static method in an abstract
class belongs to the abstract class, not potential implementations. It
therefore doesn't make any sense to allow abstract static methods.
Furthermore, static methods cannot be overridden, so again, abstract
static methods would be an anomaly.

 

[parez]

Sure, the static member in the abstract class would belong to that
class and not to the derived classes. But if it's abstract (rather
than virtual, though I think the logic would still stand for static
virtual members), what difference does it make?

Surely it makes more sense, in my example, for the MatchPattern --
which will not vary between instances of the Bar and Quux
implementations -- to be static, rather than to have to declare an
instance of Bar in order to reference its match pattern?

Anyone got any explanations that will make it all make sense to me?

Anyone got any cunning ploys that will allow me to have what is
effectively an abstract static member (and overridden static members
in the derived classes)?

All responses gratefully received,

You can do something like:

public abstract class BaseFoo
{
public static string MatchPattern { get { return ""; } }

}

public class Bar : BaseFoo
{
public static new string MatchPattern
{
get { return "[A-Za-z0-9]+"; }
}

}

It's not like you have an object that you can cast to a base class in this
instance. Virtual/abstract/override are for instance members, and static
properties aren't instances. You have to know the name of the class to access
the property.

At least, that's my understanding of it.

Chris.

Heres some thing i found online..

1)
An abstract method requires implementation per instance. Static
methods pertain to an overall class. A static method in an abstract
class belongs to the abstract class, not potential implementations. It
therefore doesn't make any sense to allow abstract static methods.
Furthermore, static methods cannot be overridden, so again, abstract
static methods would be an anomaly.

2)
You can not override a static method; therefore, you could never
implement a static abstract method.

 

[Alexander Mueller]

Ok, dumb question, I know, but I just can't get my head round it.

I'm writing a base validator class, let's call it abstract BaseFoo.
I'm also writing two implementation classes, let's call them Bar and
Quux. I want them all to share a static field that defines a regular
expression pattern used in the validation. I fail to understand why,
logically, this cannot be so. (I'm entirely willing to accept (albeit
rather frustrated) that C# just doesn't allow it, it's the *rationale*
I'm having trouble getting my head round.)

Something that is static just exists once.
If you could override or derive it, you would create it for
a second time.

See it like this:
Something that is not static, be it field, method or
class, serves as a template to create objects from
on runtime that are a 1:1 copy of this template.
Each instance of class Foo with method void Bar() has
its own void Bar() method in terms of memory and address.

A static member is not such a template but already the
real thing in terms of memory and address. It is not
cloned when the instance is being constructed.

I think that's basically the explanation why overriding or
deriving or abstracting static things would make them no longer
static.


MfG,
Alex

 

[parez]

Sure, the static member in the abstract class would belong to that
class and not to the derived classes. But if it's abstract (rather
than virtual, though I think the logic would still stand for static
virtual members), what difference does it make?

Surely it makes more sense, in my example, for the MatchPattern --
which will not vary between instances of the Bar and Quux
implementations -- to be static, rather than to have to declare an
instance of Bar in order to reference its match pattern?

Anyone got any explanations that will make it all make sense to me?

Anyone got any cunning ploys that will allow me to have what is
effectively an abstract static member (and overridden static members
in the derived classes)?

All responses gratefully received,

You can do something like:

public abstract class BaseFoo
{
public static string MatchPattern { get { return ""; } }

}

public class Bar : BaseFoo
{
public static new string MatchPattern
{
get { return "[A-Za-z0-9]+"; }
}

}

It's not like you have an object that you can cast to a base class in this
instance. Virtual/abstract/override are for instance members, and static
properties aren't instances. You have to know the name of the class to access
the property.

At least, that's my understanding of it.

Chris.

This is the third time i am trying to post to this group.. I was
trying to copy paste something i foudn on the internet...
let me type it in my own words..

Static method belongs to the the class... and NOT to potential derived
classes.....so you will not be able to override it..

 

[Jeff Louie]

Owen... The singleton pattern does allow subclassing.

Regards,
Jeff

 

[Jon Skeet [C# MVP]]

Owen... The singleton pattern does allow subclassing.

Only using a private constructor and nested subclasses - and at that
point you've got a fairly odd singleton anyway.

If you have a non-private constructor, there's just no way of
preventing (in a compile-time safe way) multiple instances from being
created.

The point of a singleton is to guarantee a single instance. If I
create a subclass, I can expose the constructor publicly, losing all
normal singleton guarantees. Sure, you can put something in the base
constructor to throw an exception if a second instance is created -
but that feels like a code smell to me.

Jon

 

[Jeff Louie]

John I am confused. The OP asked why not:

public abstract class BaseFoo
{
public static abstract string MatchPattern { get; }
}

public class Bar : BaseFoo
{
public static override string MatchPattern { get { ... } }
}

It seems to me it is possible to use instance methods and make class Bar
a Singleton.

Regards,
Jeff

 

[Jon Skeet [C# MVP]]

John I am confused. The OP asked why not:

public abstract class BaseFoo
{
public static abstract string MatchPattern { get; }
}

public class Bar : BaseFoo
{
public static override string MatchPattern { get { ... } }
}

It seems to me it is possible to use instance methods and make class Bar
a Singleton.

Bar could indeed be a singleton - but BaseFoo couldn't be.

Apologies if I misunderstood your original statement, but when you
said: "The singleton pattern does allow subclassing" I inferred that
you meant the singleton class itself can be subclassed, which it
can't. Heck, *every* singleton class is a subclass, if only of
System.Object.

On the other hand, I'm not sure that the singleton pattern really
answers the OP's problem - there's no indication that he actually
wants the class to be a singleton.

Jon

 

[Jeff Louie]

Jon... When I look at the IL from a singleton method and a static method
I don't
see a lot of difference. So this raises the ? of when to prefer a
singleton method
over a static method. This seems to be one example.

Regards,
Jeffanswers the OP's problem - there's no indication that he actually
wants the class to be a singleton<<

 

[Jon Skeet [C# MVP]]

Jon... When I look at the IL from a singleton method and a static method
I don't
see a lot of difference. So this raises the ? of when to prefer a
singleton method
over a static method. This seems to be one example.

If this method were the only thing the type was going to be used for,
that would be true - but I see no reason to assume that the OP doesn't
actually want to create instances of this type and use them as normal.
There may well be things other than the match pattern which vary
between different instances of the validator.

If the OP really wasn't ever planning on creating any instances, then
using a singleton pattern would indeed be a reasonable solution.

Jon

 

[Jeff Louie]

Owen... Hopefully this is a succinct answer to your question Why can't a
static method be abstract or virtual (overridden)?:

It is an error to declare a static method abstract or virtual.

Declaring a static method abstract prohibits instantiation of the
enclosing class. Since static methods are part of the class itself they
can be invoked without creating an instance of the class, so there is no
logic in prohibiting instantiation of the enclosing class. Declaring a
static method virtual is an error since it would result in runtime
ambiguity. If the static virtual method was overridden in more than one
subclass, the runtime would not be able to determine which
implementation to invoke.

http://www.geocities.com/jeff_louie/OOP/oop40.htm

Regards,
Jeff

 

[Orla Sorensen]

I've read this topic, but is still don't know what to do.
I would like my code to be as following, but gets an error due to
subject. Is there any way arround this problem, I would really like to
keep the methode test1 in the super class1, since it's quit complex, but
need the methode to use the value val depending on the subclass class2.

namespace ConsoleApplication1
{
abstract class Class1
{
public abstract static int val
{
get;
}

public static void test1()
{
Console.WriteLine(val);
}
}

class Class2 : Class1
{
public static override int val
{
get { return 10; }
}
}

class Program
{
static void Main(string[] args)
{
Class2.test1();
}
}
}

 

[Peter Morris]

It would be better to show what you REALLY want rather than something that
probably resembles it.

 

[Barry Kelly]

It simply makes no sense for a static member to be virtual.

Actually, it can make sense, though you'd probably want to use a
different name. C# conflates two concepts into one with its static
construct: (1) the visibility of the member - available on the type, not
requiring an instance and (2) the binding of the member, being based on
the static, compile-time type.

For example, consider this scenario:

---8<---
class A
{
public virtual string TypeName
{
get { return "A"; }
}

public override string ToString()
{
return string.Format("I'm a {0} thing", TypeName);
}
}

class B
{
public override string TypeName
{
get { return "B"; }
}
}
--->8---

Here, we are using instance virtual methods in order to get
polymorphism, but the fact that TypeName is a virtual member doesn't
mean that it needs to be an instance member. It doesn't access any
instance members. What would be wrong with wanting to access
"B.TypeName"?

-- Barry

 

[Barry Kelly]

No, not in C# it doesn't.

Sure, but I wasn't limiting my point to C#.

It's like an instance of the Sapir-Whorf hypothesis. If C#/Java/C++ are
the only kinds of languages you're[1] familiar with, then a "virtual
static members are nonsensical" may seem like a true statement in
general for object-oriented languages.

[1] I don't mean you specifically, but a generalized third party who may
be reading this and get the wrong idea.

-- Barry

 

[Jesse McGrew]

Why not? I was. This is a C# newsgroup.

There are other languages in which a type identifier is itself treatable
as an object. As an example, in Objective-C, there are class messages and
instance messages, and you can override either. I've been told that
Smalltalk is similar. No doubt lots of other languages are similar, in
that the type identifier is the type itself, rather than being a way to
use the type.

You can even do it on .NET with Delphi, where "class methods" can be
overridden (including constructors). That's a handy feature, and it's
a shame Anders left it out of C#.

Jesse