Any form of operator overloading supported in java?

[sivasu.india]

Java doesn't support multiple inheritance.To overcome that it has
provide interfaces. Is there any such way available for overloading of
operators also?

 

[Eric Sosman]

Java doesn't support multiple inheritance.To overcome that it has
provide interfaces. Is there any such way available for overloading of
operators also?

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator. The
other operator overloadings are those built into Java, and are
not extensible.

 

[ck]

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator. The
other operator overloadings are those built into Java, and are
not extensible.

Could you please cite this with a simple example? As far as I know,
Java does not allow operator overloading, though it has implicitly
done operator overloading in case of Strings.
Here what I did not understand is what you mean by

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator.

Thanks,

 

[Lew]

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator. The
other operator overloadings are those built into Java, and are
not extensible.

Could you please cite this with a simple example? As far as I know,
Java does not allow operator overloading, though it has implicitly
done operator overloading in case of Strings.
Here what I did not understand is what you mean by

StringBuffer sb = new StringBuffer();
StringBuilder bs = new StringBuilder();

The '=' and 'new' operator are (trivially) overloaded.

-- Lew

 

[ck]

StringBuffer sb = new StringBuffer();
StringBuilder bs = new StringBuilder();

The '=' and 'new' operator are (trivially) overloaded.

-- Lew

But that's implicit. But can we do operator overloading otherwise?

 

[Chris Uppal]

But that's implicit. But can we do operator overloading otherwise?

No.

The language defines small, fixed, sets of overloading for some operators, but
with those (trivial[*]) exceptions, there is no operator overloading in Java.
There is no user-defined operator overloading at all.

-- chris

[*] Arguably the built-in overloading of + to call object' toString() methods
is non-trivial, but it still isn't all that interesting...

 

[ck]

No.

The language defines small, fixed, sets of overloading for some operators, but
with those (trivial[*]) exceptions, there is no operator overloading in Java.
There is no user-defined operator overloading at all.

-- chris

[*] Arguably the built-in overloading of + to call object' toString() methods
is non-trivial, but it still isn't all that interesting...

Thanks.

 

[Eric Sosman]

ck wrote On 03/16/07 09:46,:

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator. The
other operator overloadings are those built into Java, and are
not extensible.

Could you please cite this with a simple example? As far as I know,
Java does not allow operator overloading, though it has implicitly
done operator overloading in case of Strings.
Here what I did not understand is what you mean by

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator.

I understand "operator overloading" to mean using one
operator symbol (+ or * or >>= or whatever) to represent a
a suite of different operations that apply to different
operand types. (Maybe there's a more formal definition
floating around; I dunno.) With that in mind:

- `=' is the symbol for a family of related but
different operations. There is an `=' operator
whose operands are an int variable and an int-
valued expression; there is another `=' operator
whose operands are a String reference and a String-
valued expression. Whenever I define a new class
or interface, I automatically create a matching
`=' operator whose operands are a NewClass reference
and an expression whose value is a NewClass.

- `new' is the symbol for a family of related but
different operations. Using this symbol, I can
apply an operator that constructs a String or an
operator that constructs a BigInteger or an operator
that constructs a Gizmo. Each constructable class
I define adds a new flavor of `new' to the mix.

... and so on. As I said, it's a fairly trivial form
of overloading, yet "overloading" it certainly is as far
as I can see. (Hmmm: And I should have included == and !=
among the operators that are trivially overloaded whenever
you define a new type.)

Some people seem to make a big deal out of the fact
that the `+' operator is overloaded to handle Strings.
I don't find this at all surprising or unique: `+' is
already overloaded to handle doubles, floats, longs, and
ints. Similarly, `/' is overloaded to handle doubles,
floats, longs, and ints. The four operand types lead to
four different division operations; the `/' symbol stands
for all four of them and is thus overloaded -- again, in
this rather trivial and unsurprising way.

The long and short, though, is that you cannot get
`*' to operate on your Matrix class.

 

[Chris Uppal]

Some people seem to make a big deal out of the fact
that the `+' operator is overloaded to handle Strings.
I don't find this at all surprising or unique: `+' is
already overloaded to handle doubles, floats, longs, and
ints.

I think what's significant about + overloading (unlike the overloading of *
etc) is that it invokes programmer-defined code. (It isn't quite a
programmer-defined overloading, but it shares some the problems/opportunities
thereof). For instance, there is no way of creating a "surprising"
implementation of * in the way that

public Stream
toStream()
{
System.exit(0);
}

would cause + to behave unexpectedly.

-- chris

 

[Lew]

I think what's significant about + overloading (unlike the overloading of *
etc) is that it invokes programmer-defined code. (It isn't quite a
programmer-defined overloading, but it shares some the problems/opportunities
thereof). For instance, there is no way of creating a "surprising"
implementation of * in the way that

public Stream
toStream()
{
System.exit(0);
}

would cause + to behave unexpectedly.

If one were able to define such a method in a class that overloaded +. I don't
know of an example in Java where one could.

-- Lew

 

[Chris Uppal]

Lew wrote:

[me:]

If one were able to define such a method in a class that overloaded +. I
don't know of an example in Java where one could.

You were probably mislead by the fact that I wrote toStream() when I meant
toString(). With that correction, I imagine my point comes across more clearly
;-)

-- chris

 

[Christian]

If one were able to define such a method in a class that overloaded +. I
don't know of an example in Java where one could.

-- Lew

I think he means

public String toString(){
System.exit(0);
}

?

so an objects toString would be very surprising...

there are overloadings I am missing in fact..

for example I don't understand why I can't use

< or > with two instances of comparable .. that would be convenient

- Christian

 

[Patricia Shanahan]

If one were able to define such a method in a class that overloaded +. I
don't know of an example in Java where one could.

-- Lew

public class SideEffect {
public static void main(String[] args) {
Object o = new SideEffect();
System.out.print("Hello, ");
String someString = "X" + o;
System.out.println("World");
}
public String toString(){
System.exit(3);
return null;
}
}

toString does overload part of the functionality of "+", the string
conversion step when one operand is a string and the other is a
reference expression.

Patricia

 

[Lew]

public class SideEffect {
public static void main(String[] args) { SideEffect
o = new SideEffect(); // changed from original post

System.out.print("Hello, ");

System.out.println( o ); // + overload not involved

String someString = "X" + o;
System.out.println("World");
}
public String toString(){
System.exit(3);
return null;
}

public int hashCode()
{
System.exit(4);
return super.hashCode();
}

}

toString does overload part of the functionality of "+", the string
conversion step when one operand is a string and the other is a
reference expression.

A similar issue pertains anywhere one overrides a method that is often used by
the standard API. System.out.println( o ) as above shows that. You would
certainly surprise some Collections if you put a System.exit() call in hashCode().

-- Lew

 

[The_Sage]

Date written: 16 Mar 2007 06:46:09 -0700
MsgID:<[email protected]>

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator. The
other operator overloadings are those built into Java, and are
not extensible.

Could you please cite this with a simple example? As far as I know,
Java does not allow operator overloading, though it has implicitly
done operator overloading in case of Strings.
Here what I did not understand is what you mean by

Only in a trivial sense. Defining a new class or interface
"overloads" the `=', `[]', `instanceof', and (for concrete
classes) `new' operators, and creates a new cast operator.

Don't forget the "+" operator, which Java uses for addition in math operations
and overrides in string operations for concantenating.

The Sage

=============================================================
http://members.cox.net/the.sage/index.htm

"...I contend that we are both atheists. I just believe in
one fewer god than you do. When you understand why you
dismiss all the other possible gods, you will understand why
I dismiss yours" (Stephen F. Roberts)
=============================================================

 

[fy4.net]

Java doesn't support multiple inheritance.To overcome that it has
provide interfaces. Is there any such way available for overloading of
operators also?

More see here!
http://www.flash50.com/index.php

 

[Thomas Schodt]

Some people seem to make a big deal out of the fact
that the `+' operator is overloaded to handle Strings.
I don't find this at all surprising or unique: `+' is
already overloaded to handle doubles, floats, longs, and
ints. Similarly, `/' is overloaded to handle doubles,
floats, longs, and ints. The four operand types lead to
four different division operations; the `/' symbol stands
for all four of them and is thus overloaded -- again, in
this rather trivial and unsurprising way.

As I understand it
String literals
is the reason for what some call overloading.


<http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html>
The Java language provides special support for the string concatenation
operator ( + ), and for conversion of other objects to strings. String
concatenation is implemented through the StringBuffer class and its
append method. String conversions are implemented through the method
toString, defined by Object and inherited by all classes in Java. For
additional information on string concatenation and conversion, see
Gosling, Joy, and Steele, The Java Language Specification.

<http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferMisconception>