Why can't operator overloads be abstract?

[Paul E Collins]

This code won't compile because "the modifier 'abstract' is not valid for
this item".

abstract class X
{
public abstract static bool operator >(X a, X b);
public abstract static bool operator <(X a, X b);
}

Why is that? -- apart from the obvious reason that the specification doesn't
support it. It seems like a reasonable contract to be able to enforce on
derived classes.

Similarly, interfaces can't have operator overloads. Why is *that*?

(For anybody who's curious, I read Stepanov's comment that "you can't write
a generic max() in Java that takes two arguments of some type and has a
return value of that same type", and I was messing about trying to do it in
C# 2.0. I haven't managed it yet.)

Eq.

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

Paul E Collins wrote:

This code won't compile because "the modifier 'abstract' is not valid for
this item".

abstract class X
{
public abstract static bool operator >(X a, X b);
public abstract static bool operator <(X a, X b);
}

Why is that? -- apart from the obvious reason that the specification doesn't
support it. It seems like a reasonable contract to be able to enforce on
derived classes.

Similarly, interfaces can't have operator overloads. Why is *that*?

(For anybody who's curious, I read Stepanov's comment that "you can't write
a generic max() in Java that takes two arguments of some type and has a
return value of that same type", and I was messing about trying to do it in
C# 2.0. I haven't managed it yet.)

Eq.

operators are static, and hence can't be virtual, nor abstract, it's
just the way they are implemented.

Generic max:

public static T Max<T>(T a, T b) where T: IComparable<T>
{
if (a == null) return b;
if (b == null) return a;
if (a.CompareTo(b) >= 0)
return a;
else return b;
}

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Paul E Collins wrote:

This code won't compile because "the modifier 'abstract' is not valid for
this item".

abstract class X
{
public abstract static bool operator >(X a, X b);
public abstract static bool operator <(X a, X b);
}

Why is that? -- apart from the obvious reason that the specification doesn't
support it. It seems like a reasonable contract to be able to enforce on
derived classes.

Similarly, interfaces can't have operator overloads. Why is *that*?

If you really want to know, then send an email to Anders Hejlsberg
and ask.

But if I were to make a guess.

C++ support operator overloads both as an instance member and
as a friend function.

MS wanted C# to be simpler than C++, so one of them has to go.

Some people (including me) prefer the friend function for operators
like +-*/.

And my guess is that those designing C# had the same preference
and translated C++ friend function to C# static method.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Lasse Vågsæther Karlsen wrote:

Paul E Collins wrote:

>(For anybody who's curious, I read Stepanov's comment that "you can't
write a generic max() in Java that takes two arguments of some type
and has a return value of that same type", and I was messing about
trying to do it in C# 2.0. I haven't managed it yet.)

Generic max:

public static T Max<T>(T a, T b) where T: IComparable<T>
{

Maybe we are missing something.

Because the same thing can be done in Java.

The syntax is just:

public static <T extends Comparable<? super T>T Max(T a, T b) {

Arne

[Paul E Collins]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote:

public static T Max<T>(T a, T b) where T: IComparable<T>

Ah, yes, it seems that I temporarily forgot about "where" on methods. Good
stuff.

If I'd thought a bit harder, I would have also recalled that statics can
never be inherited (so can't occur in an abstract class), but since I almost
never overload operators I didn't add the "static" until the compiler told
me to, and then I wasn't thinking about the effect on inheritance.

I'm not very familiar with Java, but if (as Arne says) the same construct is
possible then I assume that Stepanov was talking about an earlier version.

Eq.

[Rene]

Hi Paul,

If I'd thought a bit harder, I would have also recalled that statics can
never be inherited (so can't occur in an abstract class),

What do you mean when you say that statics methods are never inherited?
Looking at the code below, would you consider class "Bar" to be "inheriting"
the satic method from class "Foo"?

abstract class Foo
{
public static void DoIt()
{
}
}

abstract class Bar : Foo
{
}

class Program
{
static void Main(string[] args)
{
Bar.DoIt();
}
}

I really don't know what I am talking about here but .. I tried to come up
with a technical limitation that would explain the reason of why static
methods can't be overridden but was unable to come up with one. My guess is
that Microsoft just does not want to or has not goten around to implement
such feature but then again, I am probably missing something.

Cheers.

[Peter Duniho]

On Tue, 27 May 2008 19:01:40 -0700, Rene <[e-mail]:

[...]
I really don't know what I am talking about here but .. I tried to come
up with a technical limitation that would explain the reason of why
static methods can't be overridden but was unable to come up with one.

In spite of them being described in this thread and others?

Static methods in C# are always resolved at compile-time. Virtual methods
rely on a v-table (or at least something like that) to provide run-time
polymorphism, and in C# the only place it keeps a v-table is with an
object instance. No instance, no v-table. Without the v-table, there's
just no way to do it.

Even ignoring the implementation detail, it's a matter of C# semantics.
There would be no point in allowing virtual static methods, because you
are always required to supply the class name when calling a static
method. Because of that, you always know which class you're dealing
with. Polymorphism isn't relevant, because you never have code using
static methods that looks like it's working on one class when it's in fact
working on some other class. At compile time, you always know what class
it is.

It's not a question of "Microsoft doesn't want to" or "hasn't gotten
around to it". It's a fundamental part of the design of the language.

Pete

[Cor Ligthert[MVP]]

Paul,

So?
snip

(For anybody who's curious, I read Stepanov's comment that "you can't
write a generic max() in Java that takes two arguments of some type and
has a return value of that same type

snip

Cobol uses

If (A == x or y) to evaluate if A is equal to the value of x or the value
of y,

Has that to be in C# too?

Cor
"Paul E Collins" <fi******************@CL4.orgschreef in bericht
news:Bb******************************@bt.com...

This code won't compile because "the modifier 'abstract' is not valid for
this item".

abstract class X
{
public abstract static bool operator >(X a, X b);
public abstract static bool operator <(X a, X b);
}

Why is that? -- apart from the obvious reason that the specification
doesn't support it. It seems like a reasonable contract to be able to
enforce on derived classes.

Similarly, interfaces can't have operator overloads. Why is *that*?

(For anybody who's curious, I read Stepanov's comment that "you can't
write a generic max() in Java that takes two arguments of some type and
has a return value of that same type", and I was messing about trying to
do it in C# 2.0. I haven't managed it yet.)

Eq.

[Paul E Collins]

"Cor Ligthert[MVP]" <no************@planet.nlwrote:

Cobol uses
If (A == x or y) to evaluate if A is equal to the value of x or the value
of y,
Has that to be in C# too?

Irrelevant, because that's just a matter of syntax -- not something that
can't be stated in the language.

As Lasse showed, though, the generic max *is* possible in C#. I never said
it wasn't, only that I hadn't managed it yet.

Eq.