 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2008operator overloading
Hi, I don't find any document that say if the operator overloading will be a new feature of the Java 7 Do anyone know if it there will be? Thanks > Hi, > > I don't find any document that say if the operator overloading will be > a new feature of the Java 7 > > Do anyone know if it there will be? I don't think so. Why would you want it? Switch to C++ if you need it badly. I hope they'll do such thing. I wish they forget about closures bit its already a bit too late. Regards, Leonard  SignatureSimplicity is the ultimate sophistication. -- Leonardo da Vinci > Simplicity is the ultimate sophistication. > -- Leonardo da Vinci for the above quaotation :) It's better to write: Time t = new Time(2); Time t2 = new Time(4); Time t3 = t + t2; rather than Time t3 = Time.add(t, t2); >> Simplicity is the ultimate sophistication. >> -- Leonardo da Vinci [quoted text clipped - 11 lines] > > Time t3 = Time.add(t, t2); Well. It really depends what do you mean by ,,better''. I consider the lack of operator overloading an advantage because it helps to understand the code. Also, operator overloading is frequently abused making it very difficult to analyze the code. It is not only about reading the code. Think of all the great tools like IntelliJ IDEA. They exist only because Java is quite easy to analyze statically. While operator overloading would not prevent static analysis it would certainly make it harder. Think that it will make cost of creating good tools higher which means less tools for higher price. Think of all the people that have to learn Java. With time, Java Language Specification gets longer and longer as it incorporates more and more features. While it may be easy for you to learn new features for the new release, people starting with Java have to learn it all which gets increasingly harder. In mine opninion things like closures only pollute language while not helping anything that couldn't be addressed without them. Then think that when anything is included into Java we're stuck with it FOR LIFE or until we change the language for something different. Isn't it much for changing Time t3 = Time.add(t, t2); to Time t3 = t + t2; ? Best regards, Leonard SignatureSimplicity is the ultimate sophistication. -- Leonardo da Vinci >>> Simplicity is the ultimate sophistication. >>> -- Leonardo da Vinci [quoted text clipped - 16 lines] > the code. Also, operator overloading is frequently abused making it very > difficult to analyze the code. No. This is simply FUD and nothing more. Operator overloading was abused widely in C++; it was abused by the guys who designed the standard library (the great Bjarne himself?), and that set an example that led to it being abused by other programmers. Smalltalk has operator overloading, and it isn't abused there. Python has operator overloading, and it isn't abused there either. I can show you any number of languages with operator overloading where it isn't abused. There is nothing inherent about operator overloading that leads to abuse - the problem in C++ is a cultural one, not technical. Java's designers made the argument you made, and many even have believed it, but all this means is that they're traumatised C++ survivors, not that they're right. > It is not only about reading the code. Think of all the great tools like > IntelliJ IDEA. They exist only because Java is quite easy to analyze > statically. While operator overloading would not prevent static analysis > it would certainly make it harder. No, it would make absolutely no difference whatsoever. The syntax already includes operators, and dealing with operators as method calls just means treating "+" as a method name. > Think that it will make cost of creating good tools higher which means > less tools for higher price. [quoted text clipped - 4 lines] > for the new release, people starting with Java have to learn it all > which gets increasingly harder. They already learn how to use operators on primitives (and Strings), so that wouldn't be an additional burden for using them on objects. I doubt very much that learning to write overloaded operators would be very difficult - in other languages, they're just like normal method declarations, but with a magic word, so we might see: // C++ style public Point operator +(Point p) { return new Point((x + p.x), (y + p.y)) ; } // python style public Point __add__(Point p) { return new Point((x + p.x), (y + p.y)) ; } // Smalltalk style public Point +(Point p) { return new Point((x + p.x), (y + p.y)) ; } // let's use the hash sign for something! public Point #add(Point p) { return new Point((x + p.x), (y + p.y)) ; } // maybe something with annotations @operator(symbol="+") public Point add(Point p) { return new Point((x + p.x), (y + p.y)) ; } In any case, if you think it is too hard, just leave it for an advanced chapter. There's no huge need to teach people to write overloaded operators right at the start. In fact, it might be better not to! > In mine opninion things like closures only pollute language while not > helping anything that couldn't be addressed without them. Oh, surely you're kidding me? I take it this means you've never used a language with closures? One of the best things about python, one of the things that meant i never looked back when i switched to it from java, was the existence of lambda expressions, functions as first-class objects, and higher-order functions. > Then think that when anything is included into Java we're stuck with it > FOR LIFE or until we change the language for something different. Yes. And both closures and operator overloading are features which are well-enough understood in other languages that there is essentially no risk in adopting them in java. > Isn't it much for changing > [quoted text clipped - 5 lines] > > ? For your next exercise, try some matrix algebra with and without operator overloading. tom SignatureGot a revolution behind my eyes - We got to get up and organise Tom Anderson <twic@urchin.earth.li> quotes: >>>Time t3 = t + t2; From a person who is not a native speaker of English: Is this pronounced »T plus T two«, »T add T two«, or in yet another way? >>>Time t3 = Time.add(t, t2); If the previous sum was not pronounced using »add«, why is »add« used here instead of the pronounced word? > Tom Anderson <twic@urchin.earth.li> quotes: >>>> Time t3 = t + t2; > > From a person who is not a native speaker of English: > Is this pronounced »T plus T two«, »T add T two«, > or in yet another way? At least one native speaker of English would always pronounce it as "tee plus tee two". >>>> Time t3 = Time.add(t, t2); > > If the previous sum was not pronounced using »add«, > why is »add« used here instead of the pronounced word? I can't speak for the OP but I would do it that way because it more closely follows English grammar, in terms of word order at least. Consider: "Add salt to water" "Add salt and pepper" Although, of course you can always change the word order by expressing the idea in a more complex and awkward fashion. If I wanted to be consistent with the normal pronunciation of "+", I would write something like: Time t3 = t.plus(t2); But that might not be a good example of Java style - I'm not sure whether Java programmers would expect the value of t to be altered. BTW It doesn't really make sense (to me) to add two times together. What is 1 p.m today plus half past three yesterday? Another language has data types of DateTime and Interval and allows Intervals to be added to DateTimes. SignatureRGB >BTW It doesn't really make sense (to me) to add two times together. What >is 1 p.m today plus half past three yesterday? It should be something like: final Instant instant = new Instant( "2008-05-08T18:12:41+02:00" ); final Interval interval = new Intervall( "02:00:00" ); final Instant instant1 = instant.plus( interval ); Supersedes: <plus-20080508173952@ram.dialup.fu-berlin.de> Tom Anderson <twic@urchin.earth.li> quotes: >>>Time t3 = t + t2; From a person who is not a native speaker of English: Is this pronounced »T plus T two«, »T add T two«, or in yet another way? If the previous sum was not pronounced using »add«, why is »add« often used in expressions like t.add( t2 ) instead of the word pronounced for the operator above? > Supersedes: <plus-20080508173952@ram.dialup.fu-berlin.de> > [quoted text clipped - 4 lines] > Is this pronounced »T plus T two«, »T add T two«, > or in yet another way? Always "plus" for me. > If the previous sum was not pronounced using »add«, > why is »add« often used in expressions like > > t.add( t2 ) > > instead of the word pronounced for the operator above? It's traditional to use verbs for method names. 'Add' is a verb; 'plus' isn't. I would say that in this case, 'plus' might well be a better name, because this: a.plus(b.times(c)).dividedBy(d) Reads better than this: a.add(b.multiply(c)).divide(d) tom SignatureGot a revolution behind my eyes - We got to get up and organise > Supersedes: <plus-20080508173952@ram.dialup.fu-berlin.de> > [quoted text clipped - 4 lines] > Is this pronounced »T plus T two«, »T add T two«, > or in yet another way? The former, T plus T2. > If the previous sum was not pronounced using »add«, > why is »add« often used in expressions like > > t.add( t2 ) > > instead of the word pronounced for the operator above? "plus" is the common name of the operator symbol, the operation is actually addition and the verb is "to add". The method is named (more correctly) after the verb rather than the common name of the operator representing the operation. However, in common usage we say "plus" and the code would read more easily if the method were named "plus" [provided you knew that "plus" stood for addition]. The same also applies to "minus" (subtraction) and "times" (multiplication). Division is the odd one out. SignatureNigel Wade > >>> Simplicity is the ultimate sophistication. > >>> -- Leonardo da Vinci [quoted text clipped - 120 lines] > For your next exercise, try some matrix algebra with and without operator > overloading. It might be instructive to think about how foreach was made extensible: there is an interface which, if implemented properly, can make an arbitrary class usable in a for(each) loop. The same could be done to map syntax to operations: public interface java.lang.Indexed<T> { public T get (int i); } would, hypothetically, be enough to allow arbitrary classes to be used on the left of array expressions like: Indexed<String> notAnArray = new MyClass ("foo", "bar"); assert notAnArray[0] == "foo"; // notAnArray.get (0) assert notAnArray[1] == "bar"; // notAnArray.get (1) However, it's not clear whether the core operators (+, *, /, binary -, unary -, ++, --) should be exposed as a single interface (Arithmetic), several interfaces (Addable, Multipliable, Dividable/Rational, etc). There are also some weird edge cases (like time) where the operands and result of operations are not the same type. Consider: public class Instant { ... defines a precise moment in time ... } public class Interval { ... defines the amount of time that passes between two Instants ... } I'd normally want Instant a = ..., b = ...; Interval duration = a - b; and not Instant difference = a - b; Similarly, I'd want Instant a = ...; Interval b = ...; Instant future = a + b; // or b + a Some points to consider... -o > It might be instructive to think about how foreach was made extensible: > there is an interface which, if implemented properly, can make an [quoted text clipped - 11 lines] > assert notAnArray[0] == "foo"; // notAnArray.get (0) > assert notAnArray[1] == "bar"; // notAnArray.get (1) That's a bloody good idea. Well, it might be ... > However, it's not clear whether the core operators (+, *, /, binary -, > unary -, ++, --) should be exposed as a single interface (Arithmetic), > several interfaces (Addable, Multipliable, Dividable/Rational, etc). Both. The joy of multiple inheritance of interfaces! You need to be able to have things which you can, say, add and multiply, but not divide - anything a mathematician would call a ring, like a three-by-three matrix. Forcing these to have divide methods that just threw an exception would be pretty poor. You could even model a little hierarchy on discrete mathematics: Addable, Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends Ring, Dividable, etc. > There are also some weird edge cases (like time) where the operands > and result of operations are not the same type. There are also some distinctly non-weird non-edge cases where this is true, and where the operands are not the same type, and where you want to be able to overload the operators according to operand type. An obvious example would be a Vector3D; i want to be able to add two vectors to make a third, but also to multiply a vector by a double to get a vector, and a vector by a vector to get their dot product, which is a double. If i also have Matrix3D (being a 3 x 3 matrix, to represent linear transformations), i want to be able to add matrices, to multiply two to make a third (although i have no idea what the geometric significance of that is!), to multiply a matrix by a vector to make a transformed vector, etc. I can't see how you'd do this with interfaces unless they were defined as taking Object and returning Object, which would be a bit lame. Like how equals and compareTo work. tom SignatureGot a revolution behind my eyes - We got to get up and organise > You need to be able to have things which you can, say, add and multiply, > but not divide - anything a mathematician would call a ring, like a [quoted text clipped - 4 lines] > Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends > Ring, Dividable, etc. The question is, at the language and standard library level, do you provide four interfaces (for +, *, /, and -) or one (for all four) or five (both) or some other combination? If you provide an interface for each operator, obviously applications can define their own composite interfaces, but there may be places where the standard library uses multiple operators on a single type, so there might end up being some "standard" composite interfaces while other combinations of operators are unrepresented. If you include every possible combination of operators in the standard library, you end up with a huge number of mostly-useless interfaces. It's a hard question. (And that doesn't even get into operators like ++ and +=; I'd probably prefer to have +=, at least, implemented automatically in terms of + instead of being its own operator, but it's not a clear choice.) > > There are also some weird edge cases (like time) where the operands > > and result of operations are not the same type. [quoted text clipped - 12 lines] > I can't see how you'd do this with interfaces unless they were defined as > taking Object and returning Object, which would be a bit lame. As others have already suggested, a solution like public interface Addable<A, S> { public S add (A addend); } with generic "S"um and "A"ddend types makes the most sense. It's just, like so much in Java, unpleasantly verbose in the simple case -- a number-like class (for example, BigDecimal) would become public class BigDecimal implements Addable<BigDecimal, BigDecimal>, Comparable<BigDecimal>, ...; That's a lot of "BigDecimal"s. And since BD is not final, most of those generic types might have to be ? extends BigDecimal. > Like how equals and compareTo work. Comparable is a generic interface (and under this scheme I'd recommend just using it as-is to implement >, <, <=, and >=), so its compareTo method takes "the right type". Actually, that highlights another issue -- what to do with comparison operators? == has a well-understood existing meaning (identity comparison) that would be *very* expensive to change, as do = and !=; ===, :=, !==, =!, and <> are all ugly options. -o >> You need to be able to have things which you can, say, add and multiply, >> but not divide - anything a mathematician would call a ring, like a [quoted text clipped - 13 lines] > "standard" composite interfaces while other combinations of operators > are unrepresented. Are there really things which can be added and divided but not multiplied? How often will it be a problem that there isn't an interface for this? > If you include every possible combination of operators in the standard > library, you end up with a huge number of mostly-useless interfaces. Which is a pretty fair description of the standard library at present! > (And that doesn't even get into operators like ++ and +=; I'd probably > prefer to have +=, at least, implemented automatically in terms of + > instead of being its own operator, but it's not a clear choice.) There are times when being able to override += would be useful, because using + to synthesise it involves throwing away an object, and if they're heavyweight, that's not great. If your objects are million-by-million matrices, for instance, you'd really like to be able to add in place. One thing we definitely shouldn't have is overriding of the = operator, as C++ lets you do. That's just insane. Ditto the . operator. "Yes, but you can do some really clever things with those!", the C++ brains cry. Yeah, and i'll do something really clever with *your face* if you try it, says i. >>> There are also some weird edge cases (like time) where the operands >>> and result of operations are not the same type. [quoted text clipped - 27 lines] > > That's a lot of "BigDecimal"s. A bit of syntactic sugar which let 'this' stand for the current declaring class might help. > And since BD is not final, most of those generic types might have to be > ? extends BigDecimal. Urgh, is that how generics work? I'm not very au fait with them. Also, can i declare: public class Vector implements Multipliable<double, Vector>, Multipliable<Vector, double>, Multipliable<Matrix, Vector> ? >> Like how equals and compareTo work. > [quoted text clipped - 6 lines] > comparison) that would be *very* expensive to change, as do = and !=; > ===, :=, !==, =!, and <> are all ugly options. I don't see what's so bad about === and !==. In an ideal world, where we had operator overloading from the start, ==/!= would be the ones that punt to equals(), and ===/!== would be the ones that do identity. Like in pyhon :). tom SignatureFor the first few years I ate lunch with he mathematicians. I soon found that they were more interested in fun and games than in serious work, so I shifted to eating with the physics table. There I stayed for a number of years until the Nobel Prize, promotions, and offers from other companies, removed most of the interesting people. So I shifted to the corresponding chemistry table where I had a friend. At first I asked what were the important problems in chemistry, then what important problems they were working on, or problems that might lead to important results. One day I asked, "if what they were working on was not important, and was not likely to lead to important things, they why were they working on them?" After that I had to eat with the engineers! -- R. W. Hamming > >> You could even model a little hierarchy on discrete mathematics: Addable, > >> Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends [quoted text clipped - 3 lines] > > provide four interfaces (for +, *, /, and -) or one (for all four) or > > five (both) or some other combination? It's worth looking at the way Haskell handles operator overloading and numeric types here. There is a class of types, Num, which represent "numbers": integers, reals, rationals, complex numbers, oddities like quaternions, presumably the tensor family, whatever. Num provides +, -, *, negate (used for unary -), and abs functions, and inherits equality testing from the Eq class. Num has a subclass, Real, which also subclasses Haskell's Ord class, which in turn provides comparison operators. This is the root of most the more common numeric types, not Num. Real has two subclasses: Integral and Fractional. Both provide the / operation; the difference is in the result type. Integral in turn has two subclasses: Integer, which are bigints, and Int, which are intended to be machine ints. Dividing two Integral values can only produce another Integral; Integral also provides remainder and mod operations. Fractional's standard instances are the Float and Double types, which map to what you'd expect from other languages. Fractional specifies a / operator as well as a few other useful things. Due to the way type classes work in Haskell it's extremely easy to add new numeric types at arbitrary points in this tree and have them work "as expected" with existing code. Your hypothetical Giant Matrix type would likely be an instance of Num, and would add some operators of its own to allow for multiplication by non-Giant Matrix values like Reals. > > If you include every possible combination of operators in the standard > > library, you end up with a huge number of mostly-useless interfaces. > > Which is a pretty fair description of the standard library at present! You've a call from the org.omg package complaining about unfair representation. ;) Aside from the "obvious" cases like CORBA support, there is very little in the Java SE library that I would opt to remove. The XML support could use some streamlining, perhaps; it's gotten overgrown as Sun has gotten in the habit of declaring the XML library of the week to be "standard" and adding it. So I suspect we disagree there, or are thinking of different definitions of "standard library" (and if you start including Java EE or other javax.* packages that aren't part of the Java SE library, I'd certainly agree with you). Library design, as ever, is a series of rather hard tradeoffs. :) > > (And that doesn't even get into operators like ++ and +=; I'd probably > > prefer to have +=, at least, implemented automatically in terms of + [quoted text clipped - 4 lines] > heavyweight, that's not great. If your objects are million-by-million > matrices, for instance, you'd really like to be able to add in place. If your objects are million-by-million matrices, I would hope that you have some kind of sparse matrix structure, or some other compositional representation that doesn't actually hold all trillion elements in memory simultaneously. Large isn't *necessarily* slow, if you're clever. > One thing we definitely shouldn't have is overriding of the = operator, > as C++ lets you do. That's just insane. Ditto the . operator. No argument from me. The . and = operators only make sense in C++ because C++ has objects-as-values. I'd add -> to the list (even though the Java equivalent is .), since object indirection is a fairly core part of the language and I don't want anyone monkeying with it. > > As others have already suggested, a solution like > [quoted text clipped - 18 lines] > > Urgh, is that how generics work? I'm not very au fait with them. It Depends On What You Want. If, eg., BigDecimal implements Comparable<BigDecimal> (which it does), and you subclass BigDecimal as MyBigDecimal (which you can), then you wind up with MyBigDecimal implementing Comparable<BigDecimal>, which is actually what you want (as it allows clients to compare objects of your subclass to arbitrary BigDecimal objects). I hadn't thought through the implications completely when I wrote that, hence the "might"; now that I have time to sit and play with it a bit I think they could just be <BigDecimal> type constraints and the semantics would come out okay. > Also, can i declare: > > public class Vector implements Multipliable<double, Vector>, > Multipliable<Vector, double>, Multipliable<Matrix, Vector> > > ? No, as double is not a reference type; no, as you can't implement an interface more than once and all those generic specializations are really the same interface. The former can be worked around with the language as-is; the latter cannot. Allowing that would involve changing the way method overloads are resolved, or adding rules to forbid implementing both Multipliable<Double, Vector> and Multipliable<Vector, Vector> - as it stands, you can't provide both public Double multiply (Vector) and public Vector multiply (Vector) in the same class, because the only distinction is the return type. > -- > [The sig that ate Manhattan...] Jesus H! McQuary limit, anyone? >>>> You could even model a little hierarchy on discrete mathematics: Addable, >>>> Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends [quoted text clipped - 6 lines] > It's worth looking at the way Haskell handles operator overloading and > numeric types here. [SNIP] Thanks for that. It sounds a bit like Smalltalk's hierarchy, only a bit more rigorously thought out. >>> If you include every possible combination of operators in the standard >>> library, you end up with a huge number of mostly-useless interfaces. [quoted text clipped - 12 lines] > start including Java EE or other javax.* packages that aren't part of > the Java SE library, I'd certainly agree with you). Much or most of the standard library is indeed pretty good. There are patches where it's not, though - J2EE, XML, Swing. I often feel like i'm jumping through hoops with java.io, but only when trying to mix readers/writers and streams. >>> (And that doesn't even get into operators like ++ and +=; I'd probably >>> prefer to have +=, at least, implemented automatically in terms of + [quoted text clipped - 9 lines] > representation that doesn't actually hold all trillion elements in > memory simultaneously. No, i'm doing weather simulations. Or handling terapixel images. >> One thing we definitely shouldn't have is overriding of the = operator, >> as C++ lets you do. That's just insane. Ditto the . operator. > > No argument from me. The . and = operators only make sense in C++ > because C++ has objects-as-values. True. There are certainly positive things you can do with this power, but it's still, IMHO, too much of a headache. > I'd add -> to the list (even though the Java equivalent is .), since > object indirection is a fairly core part of the language and I don't > want anyone monkeying with it. It's that meaning of . i meant - java's ., which is C++'s ->. Java doesn't really have a .. But if it did, i would want it to be overridable! That said, python lets you override ., and it can actually be very useful at times (making proxy objects and things like that). Without python's dynamicity, it would be less useful, so i'm happy to leave it out of java. >>> As others have already suggested, a solution like >> [quoted text clipped - 20 lines] > really the same interface. The former can be worked around with the > language as-is; the latter cannot. In that case, i think any interface-based solution fails. > Allowing that would involve changing the way method overloads are > resolved, or adding rules to forbid implementing both > Multipliable<Double, Vector> and Multipliable<Vector, Vector> - as it > stands, you can't provide both public Double multiply (Vector) and > public Vector multiply (Vector) in the same class, because the only > distinction is the return type. That's fair enough. I can't think of any approach to operator overloading that would allow that without further language change. Overloading on return type is the kind of thing perl would do. >> -- >> [The sig that ate Manhattan...] > > Jesus H! McQuary limit, anyone? Apologies! I mostly have 1-3 line sigs, but i love that quote, and i couldn't see any way to trim it down. So, once in a while, i indulge myself and impose it on usenet. On average, my sig length is still well under the limit, and probably shorter than most (most who have sigs, that is). tom SignatureAnnoying others means you are wise; it is when you annoy yourself that you are truly enlightened. -- The Bullet Proof Monk > Much or most of the standard library is indeed pretty good. There are > patches where it's not, though - J2EE, XML, Swing. I often feel like i'm Those are three areas where Java libraries really shine, actually. > jumping through hoops with java.io, but only when trying to mix > readers/writers and streams. java.io is pretty straightforward. What troubles does it cause you? Normally one would want to avoid mixing Readers/Writers with Streams. The secret to getting them to work together is encoding. One can hardly blame the Java API for dealing with such a complex matter and (oh, horror) letting some of that complexity be visible to the programmer. SignatureLew >> Much or most of the standard library is indeed pretty good. There are >> patches where it's not, though - J2EE, XML, Swing. I often feel like i'm > > Those are three areas where Java libraries really shine, actually. No. >> jumping through hoops with java.io, but only when trying to mix >> readers/writers and streams. [quoted text clipped - 5 lines] > blame the Java API for dealing with such a complex matter and (oh, > horror) letting some of that complexity be visible to the programmer. I'm not convinced it does it in the best way possible. I think i was doing something where i needed to be able to read lines of text, but also things in binary, from a stream. To read lines, you need a BufferedReader, and to read binary data, you need a DataInputStream; you can wrap the BufferedReader round an InputStreamReader, and wrap that round the DataInputStream, or whatever stream underlies that. But then you have a problem, because the BufferedReader is eating more the data than it should. DataInputStream has a readLine of its own, but it'd deprecated and doesn't do character encoding. More generally, i just don't see why there needs to be a Reader/Writer hierarchy that parallels the InputStream/OutputStream hierarchy. Why not just have a Reader, which wraps an InputStream and does decoding, and a Writer, which wraps an OutputStream and does encoding? The Reader would be able to read lines, but only if on top of a PushbackInputStream. That would have solved my problem in a trice. I guess there's a case for StringReader/StringWriter too. But not the File/Buffered/whatever ones. Byte streams can provide those facilities. tom SignatureHeinlein has done more to harm SF than has any other writer, I think. -- PKD > I think i was doing something where i needed to be able to read lines of > text, but also things in binary, from a stream. To read lines, you need [quoted text clipped - 14 lines] > I guess there's a case for StringReader/StringWriter too. But not the > File/Buffered/whatever ones. Byte streams can provide those facilities. The problem is that what you're asking for covers only a handful of cases: those in which binary data gets mixed with LF-terminated (or CRLF or CR) string data. It does not cover cases where the string data is embedded in the binary data, which is far more common in the real world. The normal way to handle it is: final DataInputStream dis = new DataInputStream(...); final CharSet cs = CharSet.forName("ISO-8859-1"); final byte[] ba = new byte[32]; ... for (;;) { ... dis.readFully(ba); final String st = new String(ba, cs); ... } or, for variable-length strings, probably something like: for (;;) { ... final short l = dis.readShort(); final byte[] ba = new byte[l]; dis.readFully(ba); final String st = new String(ba, cs); ... } (Exception: if your file is /only/ to be read and written by Java, the WriteUTF and ReadUTF may be appropriate.) SignatureJohn W. Kennedy "You can, if you wish, class all science-fiction together; but it is about as perceptive as classing the works of Ballantyne, Conrad and W. W. Jacobs together as the 'sea-story' and then criticizing _that_." -- C. S. Lewis. "An Experiment in Criticism" >> Also, can i declare: >> [quoted text clipped - 12 lines] > public Double multiply (Vector) and public Vector multiply (Vector) in > the same class, because the only distinction is the return type. Multipliable<Double, Vector> would essentially provide the same service as Multipliable<double, Vector> thanks to auto-(un)boxing. Also (as the one who posted with this proposal), the idea of LHS operator overloading cannot be satisfactorily be solved in this manner; I've been racking my brains for a solution and have found known (more discussion in my earlier thread 'Java 7 Features'). This would be Tom's proposed declaration (I believe he munged the syntax), then: public class Vector implements Multipliable<Double, Vector> { } public class Matrix implements Multipliable<Double, Matrix>, Multipliable<Matrix, Matrix>, Multipliable<Vector, Vector> { } Unfortunately, to do so would still require modification such that a class can implement the same generic interface multiple times with different generic arguments--i.e., reification of generics. SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > It might be instructive to think about how foreach was made > extensible: there is an interface which, if implemented properly, can > make an arbitrary class usable in a for(each) loop. The same could be > done to map syntax to operations: > However, it's not clear whether the core operators (+, *, /, binary -, > unary -, ++, --) should be exposed as a single interface (Arithmetic), > several interfaces (Addable, Multipliable, Dividable/Rational, etc). I wonder too if it might be better to allow *new* operators, rather than change existing ones. class Matrix { public Matrix add( Matrix m ) { //... } //... } has to be invoked like this: Matrix x = y.add( z ); but what if you could call it like this: Matrix x = y .add. z; ? Just allow a more algebraic notation with method names as a convenience for those who need it. Matrix a = ( .negate. s ) .multiply. z; Hmm, unary negation bothers me... nothing on the left side... maybe it would be assumed that s has a parameterless method with the same name in that case? Same as Matrix a = ( s.negate() ).multiply( z ); I'm not sure, I'm not one of the advocates for operator overloading in Java.... > I'm not sure, I'm not one of the advocates for operator overloading in > Java.... How remarkable that you would brainstorm for a viable syntax for doing so, then. Reasons for or against operator overloading, as with so many language features current or proposed, tend to emanate from those with opinions already on the matter rather than to inform such opinions. It is refreshing and perhaps revolutionary that the users of a programming language should even imagine they have a voice in the specification of that language, let alone that we actually do. It is arguably historic. SignatureLew >> However, it's not clear whether the core operators (+, *, /, binary -, >> unary -, ++, --) should be exposed as a single interface (Arithmetic), [quoted text clipped - 21 lines] > > ? Mark, 1957 just called, FORTRAN wants its operators back. Only kidding. I quite like this idea of a general notation for infix methods. But ... > Just allow a more algebraic notation with method names as a convenience for > those who need it. > > Matrix a = ( .negate. s ) .multiply. z; It still doesn't really make maths pleasant to write. > Hmm, unary negation bothers me... nothing on the left side... maybe it would > be assumed that s has a parameterless method with the same name in that case? > Same as > > Matrix a = ( s.negate() ).multiply( z ); Yes. I don't see a problem with this. tom SignatureFinals make a man mean; let's fusc up and write! >>> However, it's not clear whether the core operators (+, *, /, binary -, >>> unary -, ++, --) should be exposed as a single interface (Arithmetic), [quoted text clipped - 26 lines] > Only kidding. I quite like this idea of a general notation for infix > methods. But ... [ SNIP ] In Haskell you can use a binary function infix, by enclosing it with backticks. E.g. > let dot x y = sum $ zipWith (*) x y > let a = [1,3,-5] > let b = [4,-2,-1] > dot a b 3 > a `dot` b 3 Similarly, operators (which are functions consisting entirely of non-alphanumeric characters), normally used infix, can be used prefix. But this is all syntactic sugar - some binary functions are easier to read infix. As far as Java goes I am now so used to Matrix x = y.add(z) that I automatically read it as "add z to y and return x". I'd find a new syntax a bit jarring myself. AHS ... > As far as Java goes I am now so used to > > Matrix x = y.add(z) > > that I automatically read it as "add z to y and return x". I'd find a new > syntax a bit jarring myself. I don't think isolated operations make the case for overloading. They seem just as readable to me in prefix method call as with arithmetic operators. We really need to think about expressions with multiple terms and operators. Here is a *very* simple example, with only half a dozen operations. Consider calculating the sum of the first n terms of an arithmetic series, given its first term, a1, and common difference, d. http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. This version is a very simple transformation of the mathematical notation. Anyone up to writing this out in prefix method call notation? Patricia > Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. > This version is a very simple transformation of the mathematical notation. > > Anyone up to writing this out in prefix method call notation? n.minus(1).times(d).plus(a1.times(2)).times(n).dividedBy(2) But yes it's hard to recognize it as the same function, even if I have it correct. Hmmm... ( n .times. ( (2 .times. a1) .plus. ( n .minus. 1) .times. d)) .dividedBy. 2; I'm still not sure this is better. Just thinking out loud... Also... m.times.n ... is that m * n, or an access to a public field "times.n" inside m. Ouch... Patricia Shanahan wrote: >> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. >> This version is a very simple transformation of the mathematical >> notation. >> >> Anyone up to writing this out in prefix method call notation? > n.minus(1).times(d).plus(a1.times(2)).times(n).dividedBy(2) ^ ^ This might break down if the methods mutate n; not if if they create new objects for the results. SignatureLew > Patricia Shanahan wrote: >>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. [quoted text clipped - 6 lines] > This might break down if the methods mutate n; not if if they create new > objects for the results. Yes. Also, the arithmetic operation would also break if arithmetic operators mutate their operands, rather than creating new values. Personally, i read it as implicit in both cases that they didn't. tom SignatureI DO IT WRONG!!! >> Patricia Shanahan wrote: >>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. [quoted text clipped - 12 lines] > > Personally, i read it as implicit in both cases that they didn't. In writing my original infix form I certainly intended operators without side effects. I would expect a "times" method that is intended as a stand-in for a multiplication operator to behave the same way. Beyond that, I think the immutable object choice that was made for BigDecimal, BigInteger, and the primitive wrappers is a good one for arithmetic objects. Patricia >Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. >This version is a very simple transformation of the mathematical notation. >Anyone up to writing this out in prefix method call notation? On can always use a program to transform an infix expression like BigDecimal( "2" )+ BigDecimal( "3" )* BigDecimal( "4" ) to a prefix expression like ( new java.math.BigDecimal( "2" ) ).add( ( new java.math.BigDecimal( "3" ) ).multiply( new java.math.BigDecimal( "4" ) ) ) with a program like #include <string> #include <iostream> #include <ostream> class BigDecimal; ::std::ostream& operator<<( ::std::ostream& os, const BigDecimal& number ); class BigDecimal { ::std::string const value_; BigDecimal const * const left_; BigDecimal const * const right_; public: explicit BigDecimal( ::std::string const value ): value_( value ), left_( 0 ), right_( 0 ){} explicit BigDecimal ( ::std::string const op, BigDecimal const * const left, BigDecimal const * const right ): value_( op ), left_( left ), right_( right ){} ::std::ostream& Print( ::std::ostream& os ) const { if( value_ == "+" ) return os << "( " << *left_ << " ).add( " << *right_ << " )"; else if( value_ == "*" ) return os << "( " << *left_ << " ).multiply( " << *right_ << " )"; else return os << "new java.math.BigDecimal( \"" << value_ << "\" )"; }}; const BigDecimal operator+ ( const BigDecimal left, const BigDecimal right ) { BigDecimal temp( "+", &left, &right ); return temp; } const BigDecimal operator* ( const BigDecimal left, const BigDecimal right ) { BigDecimal temp( "*", &left, &right ); return temp; } ::std::ostream& operator<<( ::std::ostream& os, const BigDecimal& number ) { return number.Print( os ); } int main() { ::std::cout << BigDecimal( "2" )+ BigDecimal( "3" )* BigDecimal( "4" )<< '\n'; } . Disclaimer: I do not use C++ that often, and therefore I am not sure if I got the lifetime of all temporaries right. >> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. >> This version is a very simple transformation of the mathematical notation. [quoted text clipped - 7 lines] > > ( new java.math.BigDecimal( "2" ) ).add( ( new java.math.BigDecimal( "3" ) ).multiply( new java.math.BigDecimal( "4" ) ) ) I was thinking the same thing. What is going in Java 7 is even more support for scripting. I wonder if that could be used to translate from infix to prefix. import some.package.mathscript; public class MatUtil { public Matrix transform( Matrix a, Matrix b ) { Matrix result; @<mathscript> result = (-a)*b; @</mathscript> return result; } } Looks a bit like JSP. Hmm, I wonder if that's a good thing. The need to make your own scripting engine should prevent the most cavalier abuse of this type of construct, I think. P.S. Does anyone else get surprised when their mail client doesn't auto-indent? I always am. >>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2. >>> This version is a very simple transformation of the mathematical [quoted text clipped - 10 lines] > support for scripting. I wonder if that could be used to translate from > infix to prefix. One option is to use Groovy. It uses BigDecimal by default for numeric literals: http://groovy.codehaus.org/Groovy+Math Dan. SignatureDaniel Dyer http://www.uncommons.org >> I was thinking the same thing. What is going in Java 7 is even more >> support for scripting. I wonder if that could be used to translate [quoted text clipped - 6 lines] > > Dan. Unfortunately performance is terrible. Not exactly suitable for serious maths. Mark Thornton >Unfortunately performance is terrible. Not exactly suitable for >serious maths. Another possibility would be an IDE that can display certain Java prefix expression as an infix expression in an edit box. It knows about BigDecimal and can learn about the operators and precedence rules for other classes from annotations. This has been done before: Some word processors have an internal language for mathematical terms and contain WYSIWYG formula editors for them. >> Unfortunately performance is terrible. Not exactly suitable for >> serious maths. [quoted text clipped - 8 lines] > internal language for mathematical terms and contain WYSIWYG > formula editors for them. It has been suggested many times. One concern is that without the special IDE the resulting code may be unreadable. Mark Thornton ... > import some.package.mathscript; > [quoted text clipped - 15 lines] > to make your own scripting engine should prevent the most cavalier abuse > of this type of construct, I think. ... What forms of abuse does this prevent that would not also be prevented by mapping e.g. a+b to a.add(b)? Patricia > What forms of abuse does this prevent that would not also be prevented > by mapping e.g. a+b to a.add(b)? > > Patricia I'm thinking "lazy people." People who think that typing is a lot of work and anything at all that can be done to cut down on programmer typing (as opposed to the maintainer's effort) is a good thing. Or at least it's kewl. So any class that has an "add" method will get overloaded versions of + just in the name of kewl. List myList = new List(); myList + "List Item 1"; instead of myList.add( "List Item 1" ); Then they'll overload - for remove() because if one is kewl then two are even kewler. And they'll overload ^ for contains() and % for toArray() and that'll be sooperkewl. And then someone will overload << for toString() because some *other* language they saw on the *internet* has it and then it'll all have gone to s--t. And I mean individual programmers will sub-class existing (API) classes, and writing their own classes. I'm sure Sun would never stoop to this. But there's a lot of really, really lazy programmers out there, and I don't mean that in a good "laziness is a virtue" way. Some one else on this thread said that the Java community was composed of traumatized C++ programmers. And say that's a good thing. I like to learn from my mistakes, not repeat them. ... > And I mean individual programmers will sub-class existing (API) classes, > and writing their own classes. I'm sure Sun would never stoop to this. > But there's a lot of really, really lazy programmers out there, and I > don't mean that in a good "laziness is a virtue" way. ... Sun stooped to the misuse of "+" for String concatenation. I think it should be reserved for addition. Patricia > I'm thinking "lazy people." People who think that typing is a lot of > work and anything at all that can be done to cut down on programmer > typing (as opposed to the maintainer's effort) is a good thing. Or at > least it's kewl. Almost correct, except that those people think that their cutting down on typing effort actually *HELPS* also those who maintain the code later. Signature"Too many notes" a former austrian emperor about some work of W.A.Mozart >> I'm thinking "lazy people." People who think that typing is a lot of >> work and anything at all that can be done to cut down on programmer [quoted text clipped - 4 lines] > down on typing effort actually *HELPS* also those who maintain > the code later. Really? I always figured those folks were utterly oblivious to maintenance issues, and didn't give it a thought one way or the other, choosing instead to focus on their own personal need to shave six keystrokes off of their source-code generation. SignatureLew > "Too many notes" a former austrian emperor about some work of W.A.Mozart It was not-former (at the time) Holy Roman Empire's (a.k.a. Austria's) Emperor Joseph II, referring to Mozart's 1782 composition, /Die Entführung aus dem Serail/ (/The Abduction from the Seraglio/), one of Mozart's most enduring and popular works and one for which he made no royalties. Wikipedia cites a suggestion from Conrad Wilson that the actual comment was "an extraordinary number of notes". <http://en.wikipedia.org/wiki/Die_Entf%C3%BChrung_aus_dem_Serail> At least one source misattributes the quote as a comment about /The Marriage of Figaro/. It also seems that some sources base their assertions on the movie /Amadeus/ rather than real life. SignatureLew >> "Too many notes" a former austrian emperor about some work of W.A.Mozart > Wikipedia cites a suggestion from Conrad Wilson that the actual comment was > "an extraordinary number of notes". Extraordinarily likely, the original comment was not in english language. The german version I had in mind was "Zu viele Noten", but that might indeed just be the version from the movie. I wasn't yet alive when it was originally said, and neither was any of he Wiki chroniclers ;) To go back on-Topic: If there are just more characters needed for a task, than logically necessary, this doesn't automatically help maintainers. Having simple bi=bi++; even for a BigInteger is one example that would save later maintainers much work, compared to the contortions that are now still needed for BigIntegers. I wouldn't propose "+" for anything than scalar arithmetic types. There, of course, also exist other situations, where Mark's comment really applies, and some keystrokes saved by the programmer really cost multiple on maintenance. (e.g. missing indentation, using only one-letter field-/method-names) > If there are just more characters needed for a task, than logically > necessary, this doesn't automatically help maintainers. Also true for having just fewer characters than are needed. The dicey part is knowing what is "needed". I've seen code where the use of cryptic, extremely short variable names hurt readability. I bet you have to (plural "you"). That shows that it is possible to have too few characters in a source line to help maintainers. SignatureLew >> If there are just more characters needed for a task, than logically >> necessary, this doesn't automatically help maintainers. [quoted text clipped - 6 lines] > is possible to have too few characters in a source line to help > maintainers. A classic case of short variable names is "Numerical Recipes in C" (or FORTRAN for that matter). I have a copy, and consider it valuable, but the code sucks pretty bad...what's valuable is the discussion. While the choice to use short variable names in this book was clearly driven by printing space requirements it hurts the readability badly. I understand the code in "Numerical Recipes in C++" is even worse. It's so bad that it's quite difficult to type out a code snippet from these books without making multiple errors (i.e. valid variables, just not the right ones). Among the few super-short variable names that make sense to me are i, j, k for loop indices and m, n for dimensions. Contextually these are easy to understand and help readability (I also frequently use nr and nc instead of m and n). For pretty much anything else I ensure that variable names are descriptive. I also find that I finetune variable name lengths according to their placement in code and what they are...are they object references, do they show up as arguments a lot, are they part of array index computations (*), etc. AHS * And if such a computation gets too long I pull it out and assign it to a variable. I find that readability is also hurt if the eye doesn't quickly grok to matching [] or () or {} pairs, modern IDEs notwithstanding, and doing too much inside such pairs (long variable names, lots of operators, function calls) can impair this. > A classic case of short variable names is "Numerical Recipes in C" (or > FORTRAN for that matter). I have a copy, and consider it valuable, but the [quoted text clipped - 15 lines] > show up as arguments a lot, are they part of array index computations (*), > etc. There are plenty of cases on mathematics where the traditional identifier is very short --- usually a single Greek letter. In languages that permit such identifiers there is little to be gained by using epsilon instead of ϵ. Mark Thornton >There are plenty of cases on mathematics where the traditional >identifier is very short --- usually a single Greek letter. In languages >that permit such identifiers there is little to be gained by using >epsilon instead of ϵ. You seem to have inserted the lunate epsilon U+03F5 (I am not sure whether it is quoted correctly above). It might even be a valid identifier in Java, but a small epsilon U+03B5 might look less strange. > There are plenty of cases on mathematics where the traditional > identifier is very short --- usually a single Greek letter. In languages > that permit such identifiers there is little to be gained by using > epsilon instead of ϵ. The greek letter epsilon is actually "ε" and indeed perfectly legal in Java, when using some unicode (or specifically greek) encoding. It's one of those parts, where Java is *very* permissive beyond all recommendations (which discourage use of international letters) So, in the end, there is very much gained by using "epsilon" (or "eps") instead of either ϵ or ε: portability to non-unicode systems and ease of maintenance for people who do not have these chars directly on their keyboards. PS: I fear more that people may already use international characters in their code, than what they'd do if they had operators to overload. Object ο; // This ain't ηο "o"! |> A classic case of short variable names is "Numerical Recipes in C" (or |> FORTRAN for that matter). AFAIR, with old time FORTRAN, only the first and last letters of variable names were significant, everything in between was silently ignored. Signature"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed> "I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com> > |> A classic case of short variable names is "Numerical Recipes in C" (or > |> FORTRAN for that matter). > > AFAIR, with old time FORTRAN, only the first and last letters of variable > names were significant, everything in between was silently ignored. Not in Fortran IV / 66 and newer. I don't know earlier Fortran. Arne >> |> A classic case of short variable names is "Numerical Recipes in C" >> (or |> FORTRAN for that matter). [quoted text clipped - 5 lines] > > I don't know earlier Fortran. Well - as always it is possible to find thing son the net. http://www.softwarepreservation.org/projects/FORTRAN/704_FortranProgRefMan_Oct56.pdf claims that variables names are 6 letters without any mentioning of loosing middle characters. Arne > I've seen code where the use of cryptic, extremely short variable names hurt > readability. I bet you have to (plural "you"). That shows that it is > possible to have too few characters in a source line to help maintainers. I cannot parse the second sentence. My brain tells me: "unexpected EOS". Apart from that: yes, I agree: there are cases, where too few chars do hurt a lot. We seem to disagree on whether overloadable operators would change from "too many chars" to "good", or from "good" to "too little chars". PS: both would happen, but I weigh occurrances of first more than those of the second. > We seem to disagree on whether overloadable operators would change from > "too many chars" to "good", or from "good" to "too little chars". Who told you how I feel about overloaded operators? SignatureLew >> What forms of abuse does this prevent that would not also be prevented >> by mapping e.g. a+b to a.add(b)? [quoted text clipped - 18 lines] > because some *other* language they saw on the *internet* has it and then > it'll all have gone to s--t. As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not in smalltalk, not in ada (that i've heard), not anywhere. Why do you think it'll happen in java when it hasn't happened in those languages? > And I mean individual programmers will sub-class existing (API) classes, and > writing their own classes. I'm sure Sun would never stoop to this. But > there's a lot of really, really lazy programmers out there, and I don't mean > that in a good "laziness is a virtue" way. Do you think that java programmers are, on average, more stupid than python, smalltalk or ada programmers? Actually, i could believe that. Java being the big industrial language that every idiot who doesn't fancy a career in McDonald's or Iraq is learning, and the others being a bit more niche and sophisticated. > Some one else on this thread said that the Java community was composed > of traumatized C++ programmers. And say that's a good thing. I like to > learn from my mistakes, not repeat them. Agreed. So let's learn from our mistakes and use operator overloading without abusing it. Not having operator overloading is like giving up cake because you once ate so much you were sick - don't give up cake, just practice moderation in consuming it. I don't see why we shouldn't have our cake and eat it too. tom SignatureI DO IT WRONG!!! > As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY > LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not in > smalltalk, not in ada (that i've heard), not anywhere. Why do you think > it'll happen in java when it hasn't happened in those languages? I think "disaster hasn't struck yet" is a poor counter argument. I suppose the engineer in me wants to make certain that disaster doesn't strike, with a comfortable margin of error. I like to design things that can't fail, not things that rely on above average execution by the user. > Actually, i could believe that. Java being the big industrial language > that every idiot who doesn't fancy a career in McDonald's or Iraq is Bingo. Java is far more popular than Smalltalk, Python, etc. Masses = lower average IQ, even if it's just from time pressure to get projects done. > learning, and the others being a bit more niche and sophisticated. > >> Some one else on this thread said that the Java community was composed >> of traumatized C++ programmers. And say that's a good thing. I like >> to learn from my mistakes, not repeat them. I should have said "And I say that's a good thing." Messed up the semantics there. > Agreed. So let's learn from our mistakes and use operator overloading > without abusing it. Not having operator overloading is like giving up > cake because you once ate so much you were sick - don't give up cake, I'm actually excited to try things besides operator overloading. Why *just* repeat the past? Why not invent something better? Think outside the box! The idea of embedding some form of scriptlet, or linking with .class files that were generated by a specialized parser, strikes me as potentially much more powerful than operator overloading. Just stuffing Java with every misfeature from past languages does not have me excited. I'd like to try a new misfeature. At least it won't be the same old boring misfeature we had be for, it'll be an interesting new one. ;) >> As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY >> LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not >> in smalltalk, not in ada (that i've heard), not anywhere. Why do you >> think it'll happen in java when it hasn't happened in those languages? > > I think "disaster hasn't struck yet" is a poor counter argument. I see. Do tell me about the preparations you've made in case the sun doesn't come up tomorrow morning, won't you? And how do you manage to get around without ever crossing a road? > I suppose the engineer in me wants to make certain that disaster doesn't > strike, with a comfortable margin of error. > > I like to design things that can't fail, not things that rely on above > average execution by the user. Yes, that's definitely a good thing. But there's always a tension between being an idiot-proof language and a useful language. In this case, we agree (ish) on the usefulness of operator overloading, but disagree on the proofness against idiots, and thus on whether operator overloading is a good or bad thing. >> Actually, i could believe that. Java being the big industrial language >> that every idiot who doesn't fancy a career in McDonald's or Iraq is >> learning, and the others being a bit more niche and sophisticated. > > Bingo. Java is far more popular than Smalltalk, Python, etc. Masses = lower > average IQ, even if it's just from time pressure to get projects done. I'm not sure the liberal in me is quite ready to believe this. The elitist in me certainly isn't ready to give up a useful feature for the good of the hoi polloi! >>> Some one else on this thread said that the Java community was composed of >>> traumatized C++ programmers. And say that's a good thing. I like to [quoted text clipped - 9 lines] > that were generated by a specialized parser, strikes me as potentially much > more powerful than operator overloading. ... > Just stuffing Java with every misfeature from past languages does not > have me excited. I'd like to try a new misfeature. At least it won't be > the same old boring misfeature we had be for, it'll be an interesting > new one. ;) Ah, i see where you're going with this. Hopefully, this is in a different direction to me ... tom SignatureI know you wanna try and get away, but it's the hardest thing you'll ever know >> I think "disaster hasn't struck yet" is a poor counter argument. > I see. Do tell me about the preparations you've made in case the sun > doesn't come up tomorrow morning, won't you? In this group, one should probably say explicitly, that "sun" refers to that shiny yellow ball in the sky usually visible on non-cloudy days, and not just the nickname of some company somehow related to Java language. PS: The article "the" before "sun" actually indicates the intended meaning, but may be a bit too subtle :-) >>> I think "disaster hasn't struck yet" is a poor counter argument. >> I see. Do tell me about the preparations you've made in case the sun [quoted text clipped - 7 lines] > PS: The article "the" before "sun" actually indicates the intended > meaning, but may be a bit too subtle :-) Normally I'd point to the uncapitalized spelling of "sun" to show the difference, but strictly speaking when referring to Sol, "the Sun" is a proper noun. More seriously, I saw absolutely no ambiguity in the use of "sun" in the cited passage. I'm assuming you called out the usage more for humor than for any serious advice. SignatureLew >>> I think "disaster hasn't struck yet" is a poor counter argument. >> I see. Do tell me about the preparations you've made in case the sun [quoted text clipped - 4 lines] > days, and not just the nickname of some company somehow related to > Java language. Ha! An excellent point, Herr Leitgeb, and i will endeavour to fully-qualify my nouns in future. For now, please insert an: import celestialobjects.* ; at the top of my previous post! tom SignatureArgumentative and pedantic, oh, yes. Although it's properly called "correct" -- Huge >> As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN >> ANY LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, [quoted text clipped - 5 lines] > suppose the engineer in me wants to make certain that disaster doesn't > strike, with a comfortable margin of error. ... The decision not to do something has its own risks. Consider the errors that may be made in translating formulas into Java, or the programs that will be written in Fortran or C++ rather than Java, because of Java's lack of a reasonable syntax for complex number arithmetic. Neither having nor not having operator overloading is risk free. The question, on which reasonable people can disagree, is which carries the higher cost. Patricia > Neither having nor not having operator overloading is risk free. The > question, on which reasonable people can disagree, is which carries the > higher cost. Right. So the important thing I think is to admit that we disagree, and try to find some ground where we might agree. Is there anything less that full C++ style operator-overloading that would meet your current requirement? There's a fair number of operations on matrices that don't use the simple style of algebraic operators that simple numbers use. (My poor little brain strains to remember them, however.) Should we look for a way to include those notations, and may be extend that to more maths? Can we have some set of operators that you feel you really need, and some that would be just "nice to have?" Are their any that you definitely do not need to overload? > Right. So the important thing I think is to admit that we disagree, and > try to find some ground where we might agree. Arithmetic operations on numeric/arithmetic classes seems to be just that ground. See the subthread with adapted subject. > Are there any that you definitely do not need to overload? I'd suggest those boolean operators have no such need. Multivalued logics are not widespread enough to justify it. Bitshift operators could be useful at least for BigInteger. Relation operators "<",">",">=",... would be fine too, to have overloaded, but bear the danger, that their existence could invite wrong expectations on "==" and "!=". >> Neither having nor not having operator overloading is risk free. The >> question, on which reasonable people can disagree, is which carries the [quoted text clipped - 13 lines] > some that would be just "nice to have?" Are their any that you > definitely do not need to overload? We need +, -, *, /, %, and unary - for the various kinds of complicated number. Also >, >=, <, <=; ideally, == and !=, but it's far too late for that now. Maybe we need === and !== instead. Maybe not. We need [] and []= (ie foo[bar] = baz) for composite things like matrices, and possibly collections. I'd quite like to be able to use &, |, and ^ on sets. Possibly also &=, |=, ^=. I'd like to be able to gently abuse | and ^ for vectors. If i have * as a dot product, i can use ^ for cross product and | for the resolute. So (with assigning forms being implied): essential: +, -, *, /, %, >, >=, <, <=, [], []= nice: &, |, ^ i personally don't want: ++, --, !, ~, &&, ||, ternary operator must not have: =, . I'd probably throw ++, --, ! and ~ into the bag, just for completeness. But leave the logical operators out. tom SignatureWhen you mentioned INSERT-MIND-INPUT ... did they look at you like this? > Can we have some set of operators that you feel you really need, and > some that would be just "nice to have?" Are their any that you > definitely do not need to overload? Essential: Binary operators: +,-,*,/ Unary operators: +,- On BigInteger, BigDecimal, and complex (float and double forms). Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on Big*, but not complex values. Very nice to have: [] operator for matrix element access. That would be it. Interval arithmetic and rational numbers would be nice too, but neither is in widespread use. So I would just do the set above and not implement user overloading of operators. Mark Thornton > Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on == and != are the only ones that bother me. The other comparison operators have no meaning on reference values, but == and != do. I admit, I can't think of a good use for == for references (other than inside a comparison operator to test for identity) but it would be kind of irregular for the language to treat these differently. I'm looking for a way around overloading those two, or at least a way to distinguish te |
Enable EMail Alerts
Start New Thread
Reply to this Message