«

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

wrote:
> 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.

--
Eric Sosman
lid

On Mar 16, 5:49 pm, Eric Sosman <esos...@acm-dot-org.invalid> wrote:
> 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,

--
Ck
http://www.gfour.net

Eric Sosman <esos...@acm-dot-org.invalid> wrote:
>> 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 wrote:
> 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

On Mar 16, 6:58 pm, Lew <l...@nospam.lewscanon.com> wrote:
> 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?

--
Ck

ck wrote:

> > The '=' and 'new' operator are (trivially) overloaded.
>
> 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...

On Mar 16, 7:19 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
>
> 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.

--
Ck

ck wrote On 03/16/07 09:46,:
> On Mar 16, 5:49 pm, Eric Sosman <esos...@acm-dot-org.invalid> wrote:
>
>>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.

--

Eric Sosman wrote:

> 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

Chris Uppal wrote:
> 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