| |||||||||||||
|
| |||||||||||||
Operator overloading?Operator overloading?Posted Dec 12, 2006 7:38 UTC (Tue) by mcculls (guest, #34229)In reply to: Operator overloading? by djabsolut Parent article: Sun Announces Java Platform Standard Edition 6 I wasn't party to the original decision, but there's been a RFE discussion running since 2003 which captures a lot of the pros and cons at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4905919 (has the very helpful evaluation of "I have always objected to this, but I'll leave it so people can vote" from an anonymous Sun employee!) BTW, it is possible to overload operators in some of the scripting languages built on top of the JVM, such as Groovy.
(Log in to post comments)
Operator overloading? Posted Dec 12, 2006 10:40 UTC (Tue) by eru (subscriber, #2753) [Link] I wasn't party to the original decision, but there's been a RFE discussion running since 2003 which captures a lot of the pros and cons at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4905919From one of the comments there: Operator overloading is one of the most vile, confusing, and consistently mis-used facilities of C++. It is a maintenance nightmare.. Nice to see other people feel about this issue the same way I do. Allowing operator overloading is just like promoting the use of one-character function names, with the added confusion of allowing multiple definitions for each one-character name... One could make the case for allowing it for extending arithmetic operators to handle new types (like the matrix example). That would be a good use for the feature. The problem is that a programming language cannot enforce any sane rules for this and for example prevent a "+" symbol for getting defined to do something totally unrelated to its original meaning.
Operator overloading? Posted Dec 12, 2006 11:45 UTC (Tue) by nix (subscriber, #2304) [Link] But an incompetent or evil programmer can *already* write functions called write_data() that read it, or add_numbers() that also has heaps of unexpected side effects.
It is wise to take *some* note of the effect of your language on newbies, or you end up with a language hideously hard to learn (like, well, C++). But banning features because they *might* be misused is foolish. *Any* feature can be misused.
(Far more pernicious a C++ fault is the *interaction* of operator overloading with exception handling, where you can never really tell where the hell an exception might propagate up from, because even the most innocent -> or + might throw who knows what exceptions. This is a fault which Java is mostly immune to because of checked exceptions. It would mostly be immune even if operator overloading existed.)
The one operator overload I really, really wish Java had was C++'s somewhat peculiarly-named operator()(), which lets you call an instance variable as if it were a function (whereupon operator() gets called instead). So you've gained, in effect, instanced functions with state, far nicer than mere nested functions.
Operator overloading? Posted Dec 12, 2006 12:18 UTC (Tue) by eru (subscriber, #2753) [Link] But an incompetent or evil programmer can *already* write functions called write_data() that read it, or add_numbers() that also has heaps of unexpected side effects.Sure, but at least you can fix such programs by the replace-string operation of your favourite text editor. That would be totally hopeless if the name is "+" instead of add_numbers(). It is wise to take *some* note of the effect of your language on newbies, or you end up with a language hideously hard to learn (like, well, C++). But banning features because they *might* be misused is foolish. *Any* feature can be misused. But if a feature has only a few reasonable uses (and lots of dark ones), it should not be included. I'm sure someone could come up with a good use for even the COMEFROM statement ( http://www.fortran.com/come_from.html), but I don't think it would be a good argument for including it in Java...
Operator overloading? Posted Dec 12, 2006 17:15 UTC (Tue) by tjc (guest, #137) [Link] But banning features because they *might* be misused is foolish.Well, I guess this depends on where you're coming from. People who write a lot of new code and leave it behind for others to fix and maintain tend to like expressive languages with a lot of features. On the other hand, people who spend a lot of time fixing and maintaining other people's code tend to notice that there are a lot more bad programmers out there than good, and useful features are more often than not misused.
|
|
||||||||||||