 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2007Any form of operator overloading supported in java?
Java doesn't support multiple inheritance.To overcome that it has provide interfaces. Is there any such way available for overloading of operators also? > 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.  SignatureEric Sosman esosman@acm-dot-org.invalid > 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. > 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 > 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 > > 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. > [quoted text clipped - 6 lines] > [*] 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,: >>Only in a trivial sense. Defining a new class or interface >>"overloads" the `=', `[]', `instanceof', and (for concrete [quoted text clipped - 10 lines] >>"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. SignatureEric.Sosman@sun.com > 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 > I think what's significant about + overloading (unlike the overloading of * > etc) is that it invokes programmer-defined code. (It isn't quite a [quoted text clipped - 9 lines] > > 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 [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 [quoted text clipped - 12 lines] > 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 Lew schrieb: >> I think what's significant about + overloading (unlike the overloading >> of * [quoted text clipped - 16 lines] > > -- 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 >> I think what's significant about + overloading (unlike the overloading >> of * [quoted text clipped - 16 lines] > > -- 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 > 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"); [quoted text clipped - 3 lines] > 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 > Some people seem to make a big deal out of the fact > that the `+' operator is overloaded to handle Strings. [quoted text clipped - 5 lines] > 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> >Reply to article by: "ck" <chandankumar.r@gmail.com> >Date written: 16 Mar 2007 06:46:09 -0700 >MsgID:<1174052769.443473.182200@e65g2000hsc.googlegroups.com> >> 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) ============================================================= On 3月16日, 下午5时37分, "sivasu.in...@gmail.com" <sivasu.in...@gmail.com> 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.