Any form of operator overloading supported in java?

Discussion in 'Java' started by sivasu.india@gmail.com, Mar 16, 2007.

  1. Guest

    Java doesn't support multiple inheritance.To overcome that it has
    provide interfaces. Is there any such way available for overloading of
    operators also?
    , Mar 16, 2007
    #1
    1. Advertising

  2. Eric Sosman Guest

    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
    Eric Sosman, Mar 16, 2007
    #2
    1. Advertising

  3. ck Guest

    On Mar 16, 5:49 pm, Eric Sosman <> 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
    ck, Mar 16, 2007
    #3
  4. Lew Guest

    Eric Sosman <> 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
    Lew, Mar 16, 2007
    #4
  5. ck Guest

    On Mar 16, 6:58 pm, Lew <> 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, Mar 16, 2007
    #5
  6. Chris Uppal Guest

    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...
    Chris Uppal, Mar 16, 2007
    #6
  7. ck Guest

    On Mar 16, 7:19 pm, "Chris Uppal" <-
    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, Mar 16, 2007
    #7
  8. Eric Sosman Guest

    ck wrote On 03/16/07 09:46,:
    > On Mar 16, 5:49 pm, Eric Sosman <> 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, Mar 16, 2007
    #8
  9. Chris Uppal Guest

    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, Mar 17, 2007
    #9
  10. Lew Guest

    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
    Lew, Mar 17, 2007
    #10
  11. Chris Uppal Guest

    Lew wrote:

    [me:]
    > > 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.


    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
    Chris Uppal, Mar 17, 2007
    #11
  12. Christian Guest

    Lew schrieb:
    > 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


    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
    Christian, Mar 17, 2007
    #12
  13. Lew wrote:
    > 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


    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
    Patricia Shanahan, Mar 17, 2007
    #13
  14. Lew Guest

    Patricia Shanahan wrote:
    > 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

    Collection< SideEffect > stuff = new HashSet< SideEffect > ();
    stuff.add( o ); // this really makes a hash of things

    > 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
    Lew, Mar 17, 2007
    #14
  15. The_Sage Guest

    >Reply to article by: "ck" <>
    >Date written: 16 Mar 2007 06:46:09 -0700
    >MsgID:<>


    >> 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)
    =============================================================
    The_Sage, Mar 18, 2007
    #15
  16. Guest

    On 3ÔÂ16ÈÕ, ÏÂÎç5ʱ37·Ö, "" <>
    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?


    More see here!
    http://www.flash50.com/index.php
    , Mar 18, 2007
    #16
  17. 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. 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>
    Thomas Schodt, Mar 18, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Smith
    Replies:
    2
    Views:
    417
    Ivan Vecerina
    Oct 6, 2004
  2. Replies:
    11
    Views:
    727
    James Kanze
    May 16, 2007
  3. hurcan solter
    Replies:
    3
    Views:
    725
    Cholo Lennon
    Aug 29, 2007
  4. Replies:
    11
    Views:
    557
  5. Replies:
    2
    Views:
    307
Loading...

Share This Page