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

[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

*** Sent via Developersdex http://www.developersdex.com ***

[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 ConsoleApplicat ion1
{
abstract class Class1
{
public abstract static int val
{
get;
}

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

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

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

*** Sent via Developersdex http://www.developersdex.com ***

[Peter Morris]

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

[Peter Duniho]

On Fri, 16 May 2008 01:27:31 -0700, Orla Sorensen <cs****@orlaus. dkwrote:

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.

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

In the code example you've provided, the most obvious solution I see is to
make the method "test1()" take a parameter, then provide a different
"call_test1 ()" method in each class that calls "test1()" with the
appropriate value. That way, each class has its own public version of the
method appropriate to the value in the class, but they both can use the
common implementation in the base class.

There are other approaches that might also work, but as Peter M. notes,
without a more clear higher-level description of what you're really trying
to do, it's hard to provide suggestions.

Pete

[Barry Kelly]

Peter Duniho wrote:

On Fri, 16 May 2008 13:33:41 -0700, Barry Kelly <ba***********@ gmail.com>
wrote:

Peter Duniho wrote:

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

Actually, it can make sense,

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

--
http://barrkel.blogspot.com/

[Peter Duniho]

On Fri, 16 May 2008 15:38:56 -0700, Barry Kelly <ba***********@ gmail.com>
wrote:

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

Actually, it can make sense,

No, not in C# it doesn't.

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

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.

But this is C#. We're talking about C#, where the type identifier is a
different entity than the type itself. Saying "what could be" doesn't
help anyone trying to write C# code.

At the very least, if you're going to diverge from the topic, I think you
should be more explicit about your comments. Someone reading your post
might be misled into thinking that virtual static members "actually.. .can
make sense" even in C#.

Pete

[Jesse McGrew]

On May 16, 4:30 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Fri, 16 May 2008 15:38:56 -0700, Barry Kelly <barry.j.ke...@ gmail.com>
wrote:

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

Actually, it can make sense,

No, not in C# it doesn't.

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

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