only static operators?

[Silver Phoenix]

Greetings.

I have some questions that I would like to clear out.

1. Why do operators have to be static? (This question relates to the
language specification)

2. More importantly, couldn't there be operators that were tranlated at
compile-time to "normal" methods?

For example:

bool operator ==(T something);

would be translated to:

bool operator_equal( T something);

At code it would be used as:

T a = new T();
T b = new T();
if(a == b)
// ...

and it would be translated as:

T a = new T();
T b = new T();
if( a.operator_equa l(b) )
// ...

This translation would permit using overloaded operators in VB .NET and J#,
and maintain the C++ operators.
Plus, the Object class could have the == operator overloaded as:

public bool operator ==(object obj)
{
return Equals(obj);
}

The most important question is: Does someone know why wasn't this feature
placed in the CLS?
I don't see how it would break type safety.

Thank you for your attention.

[Lasse Vågsæther Karlsen]

Silver Phoenix wrote:

Greetings.

I have some questions that I would like to clear out.

1. Why do operators have to be static? (This question relates to the
language specification)

T a = null;
if (someOtherCrite ria)
a = new T();
....
if (a != null)
// do something with a

-->

if (!(null reference).op_e qual(null))
--> NullReferenceEx ception

By making it static, both sides of the comparison is passed as
parameters. If you allowed the above, what would be the expected
behaviour when you did the above ? NullReferenceEx ception or yield false
as an implicit result ? if the latter, what about these two:

if (a == null)
if (a != null)

how would the compiler know what to yield in these two cases if a is
actually null, true in the first and false in the second ? that would
mean the compiler has pre-knowledge about how the operator would work
and in fact never call the method if a is null.

I see your point, but I'm not sure there would be a coherent
specification for this if you were to handle all the cases.

Also, this might be wrong:

if ((SomeBaseType) someDescendedOb ject == otherObject)
...

do you use the SomeBaseType comparison (since you typecasted) or do you
use the virtual op_equal operator defined in the object referred to by
someDescendedOb ject ? If the former, that would break the way "virtual"
works, if the latter you explicitly states that there is no way to get a
different behaviour when doing comparisons.

--
Lasse Vågsæther Karlsen
http://www.vkarlsen.no/
mailto:la***@vk arlsen.no
PGP KeyID: 0x0270466B

[Silver Phoenix]

So simple, that I missed it.

Thank you.

[Benoit Vreuninckx]

Silver Phoenix wrote:

Greetings.

I have some questions that I would like to clear out.

1. Why do operators have to be static? (This question relates to the
language specification)

2. More importantly, couldn't there be operators that were tranlated at
compile-time to "normal" methods?

For example:

bool operator ==(T something);

would be translated to:

bool operator_equal( T something);

At code it would be used as:

T a = new T();
T b = new T();
if(a == b)
// ...

and it would be translated as:

T a = new T();
T b = new T();
if( a.operator_equa l(b) )
// ...

This translation would permit using overloaded operators in VB .NET and J#,
and maintain the C++ operators.
Plus, the Object class could have the == operator overloaded as:

public bool operator ==(object obj)
{
return Equals(obj);
}

The most important question is: Does someone know why wasn't this feature
placed in the CLS?
I don't see how it would break type safety.

Thank you for your attention.

Hi,

regarding your second question, overloaded operators *are* normal
methods, so, for instance, the + operator is translated to op_Addition.
Overloaded operators aren't part of the CLS as not all languages support
overloading of operators. BTW, CLS has nothing to do with type safety,
it just specifies which language constructs must be available in a
language for it to be CLS compliant.

Cheers,
Benoit