digitalmars.D - Why Java Doesn't Need Operator Overloading (and Very Few Languages Do, Really)
- Paul D. Anderson (6/6) Apr 14 2009 Sounds like someone needs a strong dose of D!!
- Ellery Newcomer (2/13) Apr 14 2009 How about a language where expression overloading is available, etc?
- Robert Fraser (11/22) Apr 14 2009 OT: that article mentioned one of my biggest pet peeves:
- Walter Bright (2/2) Apr 14 2009 My problem with operator overloading stemmed from C++'s endorsement of
- Rainer Deyke (8/10) Apr 14 2009 I don't see how "stream << value" is any worse than "shift_left(stream,
- Simen Kjaeraas (17/25) Apr 14 2009 The problem with operator overloading as compared to function overloadin...
- hasen (3/5) Apr 14 2009 You know, I never knew << meant bit shifting until my assembly course at...
- Don (9/11) Apr 15 2009 I saw someone who wrote a database library, and used << and >> for
- Walter Bright (2/17) Apr 15 2009 Adding in < and > for templates just makes it all worth while!
-
Daniel Keep
(4/19)
Apr 16 2009
db
y; // copy x to y - bearophile (4/4) Apr 14 2009 Paul D. Anderson:
- Don (12/23) Apr 15 2009 He says he doesn't like it because:
- bearophile (13/14) Apr 15 2009 Are there few non-arithmetic operators (that will support operator overl...
- Don (13/32) Apr 15 2009 Not many. I did look through all the unicode symbols, and even there,
- Robert Fraser (2/3) Apr 15 2009 a ♥ b
- Jarrett Billingsley (3/8) Apr 15 2009 opLove.
- Yigal Chripun (14/22) Apr 15 2009 sounds silly to me. Why not simply generalize and allow defining in-fix
- BCS (2/5) Apr 15 2009 lexing and (more importantly) parsing become a major problem if you allo...
- Yigal Chripun (4/11) Apr 15 2009 Since it is done in other languages (for example Scala), I'm sure it's
- Daniel Keep (9/25) Apr 16 2009 That's not a very good argument. Lots of things are possible; doesn't
- Yigal Chripun (15/53) Apr 17 2009 say we have the expression (2 + 3 foo 4) (foo is infix function).
- Christopher Wright (10/38) Apr 15 2009 This reminds me of something I did at work. C# 2.0 has no builtin syntax...
- Walter Bright (6/17) Apr 15 2009 Even worse, by standardizing the << and >> for streams, C++ implicitly
-
The Anh Tran
(8/8)
Apr 15 2009
- The Anh Tran (7/21) Apr 15 2009 Clarification:
- Walter Bright (2/9) Apr 16 2009 You can still do expression templates in D.
- Paul D. Anderson (3/9) Apr 15 2009 I agree -- that's what I was (sarcastically) trying to point out. I wrot...
- Edward Diener (27/36) Apr 18 2009 Java's lack of operator overloading is the most idiotic language
- Andrei Alexandrescu (6/50) Apr 18 2009 This has happened before. Somehow Java has this penchant for attracting
- grauzone (1/5) Apr 18 2009 D has this too.
- Andrei Alexandrescu (4/10) Apr 18 2009 Probably a lot of language enthusiasts do this at some point or another....
Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm... Paul
Apr 14 2009
Paul D. Anderson wrote:Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm... PaulHow about a language where expression overloading is available, etc?
Apr 14 2009
Paul D. Anderson wrote:Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm... PaulOT: that article mentioned one of my biggest pet peeves: ""Doesn't it make much more sense to use add() for a List and put() for a Map?"" In that case it doesn't matter too much since the interface for the two functions is different. However, adding a single element to a collection should have an add() (or +=, or whatever), so that the type of the collection can be changed/abstracted away (e.x. made a template argument). This is particularly annoying with "enqueue"/"push" and "dequeue"/"pop", since there are often times you'd want to change between stacks and queues without changing the algorithm used.
Apr 14 2009
My problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.
Apr 14 2009
Walter Bright wrote:My problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.I don't see how "stream << value" is any worse than "shift_left(stream, value)". Most operators are just functions with special syntax. No more, no less. The issues with operator overloading are exactly the same as the issues with function overloading. -- Rainer Deyke - rainerd eldwood.com
Apr 14 2009
On Wed, 15 Apr 2009 02:29:33 +0200, Rainer Deyke <rainerd eldwood.com> wrote:Walter Bright wrote:The problem with operator overloading as compared to function overloading is that they are generally shorter, and thus some programmers want to use them not because they make logical sense but because they lead to less typing. Also, some operators (<<, for instance) may seem to make sense in situations where many would think they do not. shift_left(stream, value) would simply not be used to output 'value' to 'stream', while stream << value is provably being used like that, even though the meaning I can glean from the two is equal. I fear C++'s '<<' was a prime example of 'look what I can do'. I read a nice text about operator overloading some time ago, that likened it to function naming. Basically, the argument that operator overloading can be abused and thus no programmer should be trusted to use it is no different from saying function naming can be abused and thus no programmer should be allowed to choose the names of functions. -- SimenMy problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.I don't see how "stream << value" is any worse than "shift_left(stream, value)". Most operators are just functions with special syntax. No more, no less. The issues with operator overloading are exactly the same as the issues with function overloading.
Apr 14 2009
Walter Bright wrote:My problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.You know, I never knew << meant bit shifting until my assembly course at university!!
Apr 14 2009
Walter Bright wrote:My problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.I saw someone who wrote a database library, and used << and >> for stream operations. Then he needed a second form of stream operations, so he overloaded > and <. db < x < y; // stores x and y in the database (db < x) < 7; // stores x and 7 in the database db < (x < 7); // stores a bool in the database. if (db > x) { zzz; } // gets x from the database, then does zzz. What fun!
Apr 15 2009
Don wrote:Walter Bright wrote:Adding in < and > for templates just makes it all worth while!My problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.I saw someone who wrote a database library, and used << and >> for stream operations. Then he needed a second form of stream operations, so he overloaded > and <. db < x < y; // stores x and y in the database (db < x) < 7; // stores x and 7 in the database db < (x < 7); // stores a bool in the database. if (db > x) { zzz; } // gets x from the database, then does zzz. What fun!
Apr 15 2009
Don wrote:Walter Bright wrote:db<x> y; // copy x to y :D -- DanielMy problem with operator overloading stemmed from C++'s endorsement of using >> and << for stream operations.I saw someone who wrote a database library, and used << and >> for stream operations. Then he needed a second form of stream operations, so he overloaded > and <. db < x < y; // stores x and y in the database (db < x) < 7; // stores x and 7 in the database db < (x < 7); // stores a bool in the database. if (db > x) { zzz; } // gets x from the database, then does zzz. What fun!
Apr 16 2009
Paul D. Anderson: Having some operator overload is good if you write some numerical/scientific code. Try working with bignumbers or vectors in Java, and you will see how quickly some otherwise simple expressions become an unreadable mess. Bye, bearophile
Apr 14 2009
Paul D. Anderson wrote:Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm... PaulHe says he doesn't like it because: The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices). Bingo! That's what operator overloading is for. **Don't overload arithmetic operators unless you are doing arithmetic.** I think the main problem with operator overloading in C++ is that that point wasn't explained well at all. The D spec could probably do a better job of it, but at least the ~ operator removes the temptation for people to use + to mean concatenation.
Apr 15 2009
Don:**Don't overload arithmetic operators unless you are doing arithmetic.**<Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D? The main problems here are that such operators are very few, they may end being used only in special situations, so may be unworth being added to the language, and of course ASCII has very few symbols fit for such purpose. For example I have implemented in D the Python sets with (almost) the same semantics (it's not equal because the operator overlading of D is a bit less powerful than the Python one. No one has so far given me an answer about this silly limit). Some of their operators/methods are: s.issubset(t) s <= t test whether every element in s is in t s.issuperset(t) s >= t test whether every element in t is in s s.union(t) s | t new set with elements from both s and t s.intersection(t) s & t new set with elements common to s and t s.difference(t) s - t new set with elements in s but not in t s.symmetric_difference(t) s ^ t new set with elements in either s or t but not both So you end using <= => | & ^ - for set operations too, but in real math you want to use a different set of symbols here. And such standard set of symbols is more readable (and unambiguous) compared to that ASCII mapping. APL (and the following languages like J/K/etc) is unreadable also because the symbols it uses are not standard outside the language. Bye, bearophile
Apr 15 2009
bearophile wrote:Don:Not many. I did look through all the unicode symbols, and even there, there's not many you'd want. Generally, unary operations aren't necessary (a function call looks quite OK). __dot, __cross would be the most useful. They are arithmetic, of course. Set operations. __union, __intersection, __subset, __superset, __subseteq, __superseteq. After that things get really obscure and pretty hard to justify. But __dot would be extremely valuable, I think. Especially since we have array operations in the language, and a[]*b[] is defined as element-wise multiplication. An IDE/text editor could translate __dot into the relevant Unicode character.**Don't overload arithmetic operators unless you are doing arithmetic.**<Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D? The main problems here are that such operators are very few, they may end being used only in special situations, so may be unworth being added to the language, and of course ASCII has very few symbols fit for such purpose.For example I have implemented in D the Python sets with (almost) the same semantics (it's not equal because the operator overlading of D is a bit less powerful than the Python one. No one has so far given me an answer about this silly limit). Some of their operators/methods are: s.issubset(t) s <= t test whether every element in s is in t s.issuperset(t) s >= t test whether every element in t is in s s.union(t) s | t new set with elements from both s and t s.intersection(t) s & t new set with elements common to s and t s.difference(t) s - t new set with elements in s but not in t s.symmetric_difference(t) s ^ t new set with elements in either s or t but not both So you end using <= => | & ^ - for set operations too, but in real math you want to use a different set of symbols here. And such standard set of symbols is more readable (and unambiguous) compared to that ASCII mapping. APL (and the following languages like J/K/etc) is unreadable also because the symbols it uses are not standard outside the language. Bye, bearophile
Apr 15 2009
bearophile wrote:Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D?a ♥ b
Apr 15 2009
On Wed, Apr 15, 2009 at 10:31 AM, Robert Fraser <fraserofthenight gmail.com> wrote:bearophile wrote:opLove.Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D?a =A2=BE b
Apr 15 2009
On 15/04/2009 18:25, Jarrett Billingsley wrote:On Wed, Apr 15, 2009 at 10:31 AM, Robert Fraser <fraserofthenight gmail.com> wrote:sounds silly to me. Why not simply generalize and allow defining in-fix functions like in functional languages? that also includes allowing any unicode character[s]. for example, why not allow: if (M ⊨ a ∨ b) { ... } or: (a concat b concat c) [same as (a ~ b ~ c)] or: if (A dated B || B dated A) { .. } the current system is too limiting, maybe that's why it's more susceptible to being abused? if C++ had this, I'm sure that the awful << for streams wouldn't have been used.bearophile wrote:opLove.Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D?a ♥ b
Apr 15 2009
Hello Yigal,sounds silly to me. Why not simply generalize and allow defining in-fix functions like in functional languages? that also includes allowing any unicode character[s].lexing and (more importantly) parsing become a major problem if you allow that
Apr 15 2009
On 15/04/2009 18:50, BCS wrote:Hello Yigal,Since it is done in other languages (for example Scala), I'm sure it's not impossible to implement. I don't think Scala is that much more troublesome to lex/parse.sounds silly to me. Why not simply generalize and allow defining in-fix functions like in functional languages? that also includes allowing any unicode character[s].lexing and (more importantly) parsing become a major problem if you allow that
Apr 15 2009
Yigal Chripun wrote:On 15/04/2009 18:50, BCS wrote:That's not a very good argument. Lots of things are possible; doesn't mean they're a good idea. Operator precedence determines how expressions are parsed. Having user-defined operators would require the code to be parsed once to get the operator definitions, then re-parsed with a different meaning. Euch. That said, I'm OK with adding operators with well-defined meanings to the language on an as-needed basis. opDot, opUnion, opCross, etc. -- DanielHello Yigal,Since it is done in other languages (for example Scala), I'm sure it's not impossible to implement. I don't think Scala is that much more troublesome to lex/parse.sounds silly to me. Why not simply generalize and allow defining in-fix functions like in functional languages? that also includes allowing any unicode character[s].lexing and (more importantly) parsing become a major problem if you allow that
Apr 16 2009
On 16/04/2009 15:47, Daniel Keep wrote:Yigal Chripun wrote:say we have the expression (2 + 3 foo 4) (foo is infix function). Scala parses this as: 2 + 3.foo(4) so there is no parsing problems with this. see http://www.scala-lang.org/node/118 Eiffel is similar (also an OOP approach): 2 + 4 is the same as 2.plus(4) the definition of plus is (alias is used to specify the operator):On 15/04/2009 18:50, BCS wrote:That's not a very good argument. Lots of things are possible; doesn't mean they're a good idea. Operator precedence determines how expressions are parsed. Having user-defined operators would require the code to be parsed once to get the operator definitions, then re-parsed with a different meaning. Euch. That said, I'm OK with adding operators with well-defined meanings to the language on an as-needed basis. opDot, opUnion, opCross, etc. -- DanielHello Yigal,Since it is done in other languages (for example Scala), I'm sure it's not impossible to implement. I don't think Scala is that much more troublesome to lex/parse.sounds silly to me. Why not simply generalize and allow defining in-fix functions like in functional languages? that also includes allowing any unicode character[s].lexing and (more importantly) parsing become a major problem if you allow thatplus alias "+" (other: INTEGER): INTEGER -- ... Normal function declaration... endfrom wikipedia for Eiffel:The range of operators that can be used as "alias" is quite broad; they include predefined operators such as "+" but also "free operators" made of non-alphanumeric symbols. This makes it possible to design special infix and prefix notations, for example in mathematics and physics applications. Every class may in addition have one function aliased to "[]", the "bracket" operator, allowing the notation a [i, ...] as a synonym for a.f (i, ...) where f is the chosen function. This is particularly useful for container structures such as arrays, hash tables, lists etc.in Haskell you can define both precedence and associativity for operators. I don't know Haskell but found this link which explains the syntax: http://www.haskell.org/tutorial/functions.html I guess we need someone who knows Haskell to explain how they implemented this.
Apr 17 2009
Don wrote:Paul D. Anderson wrote:for associative arrays, and we needed to create a lot of dictionaries of string -> object. We came up a little class with operator overloads: operator[string,object] added a dictionary entry and returned the dictionary builder. But when you're done with that, you still need to convert to a dictionary. So we added an operator overload for this. Now we format strings like: _formatter.Format("${hello} ${world}", -Using.Values["hello", helloObject]["world", worldObject]);Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm... PaulHe says he doesn't like it because: The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices). Bingo! That's what operator overloading is for. **Don't overload arithmetic operators unless you are doing arithmetic.** I think the main problem with operator overloading in C++ is that that point wasn't explained well at all. The D spec could probably do a better job of it, but at least the ~ operator removes the temptation for people to use + to mean concatenation.
Apr 15 2009
Don wrote:The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices).Exactly right.Bingo! That's what operator overloading is for. **Don't overload arithmetic operators unless you are doing arithmetic.** I think the main problem with operator overloading in C++ is that that point wasn't explained well at all.Even worse, by standardizing the << and >> for streams, C++ implicitly endorsed non-arithmetic usages.The D spec could probably do a better job of it, but at least the ~ operator removes the temptation for people to use + to mean concatenation.Yeah, does + mean vector addition or concatenation? There's no solution to that problem if you don't have ~.
Apr 15 2009
<Begging/crying inside> Dear Mr Bright, "iostream <<" is BAD; but for something else, it is not very terrible. So, please give us the operator Freedom as in C++ !!!!! The compiler could throw scary error: "operator abuser spotted!!! Need "-opAbuser" to compile this file" </end> ;-D
Apr 15 2009
The Anh Tran wrote:<Begging/crying inside> Dear Mr Bright, "iostream <<" is BAD; but for something else, it is not very terrible. So, please give us the operator Freedom as in C++ !!!!! The compiler could throw scary error: "operator abuser spotted!!! Need "-opAbuser" to compile this file" </end> ;-DClarification: I mean something else is expression template. Current solution is mixin("blahblahblah"), like Andrei's newest piece of art std.algorithm. I think we could write nicer code than mixin if we have more operator. Best regards.
Apr 15 2009
The Anh Tran wrote:Clarification: I mean something else is expression template. Current solution is mixin("blahblahblah"), like Andrei's newest piece of art std.algorithm. I think we could write nicer code than mixin if we have more operator.You can still do expression templates in D.
Apr 16 2009
bearophile Wrote:Paul D. Anderson: Having some operator overload is good if you write some numerical/scientific code. Try working with bignumbers or vectors in Java, and you will see how quickly some otherwise simple expressions become an unreadable mess. Bye, bearophileI agree -- that's what I was (sarcastically) trying to point out. I wrote a very large (for one person) application in Java using BigDecimal and I was ready to spit bullets before it was done. Paul
Apr 15 2009
Paul D. Anderson wrote:Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm...Java's lack of operator overloading is the most idiotic language decision which I have ever encountered. The arguments against operator overloading are equivalent to "if we allow feature X, programmers might not use it the way we have decided it should be used, therefore we won't allow it". "Idiotic" is not even a strong enough word to describe the retrograde thinking of the Java fanatics, and Sun, who have decided to tell programmers what is good for them, whether they want to swallow that pill or not. Java is the only major language I use which does not have operator Among other things this means that while 1 + 2 in Java is valid, if I write a BigInteger Java class I must write: BigInteger a = 1; BigInteger b = 2; BigInteger c = a.Add(b); or some such other nonsense rather than the completely natural BigInteger c = a + b;. To say that the lack of operator overloading in Java somehow makes the language "better" or "clearer to use" is so ludicrous it needs no further comment. Eventually Java will add operator overloading, since Sun's fanaticism is clearly earning them a quick exit into buyout land ( if not IBM today it will be someone else tomorrow ). Then everyone from the Java fanatic camp will smile and say "wasn't that a brilliant decision Sun made", as if it hadn't been made by everyone else ages ago. Sorry for the non-D related diatribe but someone else started this thread and I can't help remarking how stupid a language must be in this day and time which does not support operator overloading for ease of syntax use.
Apr 18 2009
Edward Diener wrote:Paul D. Anderson wrote:This has happened before. Somehow Java has this penchant for attracting odd groupies. Pretty much every feature that Java didn't have was vilified by zealots until adoption, when all of a sudden it became a brilliant decision. AndreiSounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm...Java's lack of operator overloading is the most idiotic language decision which I have ever encountered. The arguments against operator overloading are equivalent to "if we allow feature X, programmers might not use it the way we have decided it should be used, therefore we won't allow it". "Idiotic" is not even a strong enough word to describe the retrograde thinking of the Java fanatics, and Sun, who have decided to tell programmers what is good for them, whether they want to swallow that pill or not. Java is the only major language I use which does not have operator Among other things this means that while 1 + 2 in Java is valid, if I write a BigInteger Java class I must write: BigInteger a = 1; BigInteger b = 2; BigInteger c = a.Add(b); or some such other nonsense rather than the completely natural BigInteger c = a + b;. To say that the lack of operator overloading in Java somehow makes the language "better" or "clearer to use" is so ludicrous it needs no further comment. Eventually Java will add operator overloading, since Sun's fanaticism is clearly earning them a quick exit into buyout land ( if not IBM today it will be someone else tomorrow ). Then everyone from the Java fanatic camp will smile and say "wasn't that a brilliant decision Sun made", as if it hadn't been made by everyone else ages ago. Sorry for the non-D related diatribe but someone else started this thread and I can't help remarking how stupid a language must be in this day and time which does not support operator overloading for ease of syntax use.
Apr 18 2009
This has happened before. Somehow Java has this penchant for attracting odd groupies. Pretty much every feature that Java didn't have was vilified by zealots until adoption, when all of a sudden it became a brilliant decision.D has this too.
Apr 18 2009
grauzone wrote:Probably a lot of language enthusiasts do this at some point or another. For some reason this NIH syndrome is more prevalent in Java communities. AndreiThis has happened before. Somehow Java has this penchant for attracting odd groupies. Pretty much every feature that Java didn't have was vilified by zealots until adoption, when all of a sudden it became a brilliant decision.D has this too.
Apr 18 2009