Re: News for Java?
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-1814140200-1294499690=:7448
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Sat, 8 Jan 2011, Lew wrote:
On 01/08/2011 08:36 AM, Tom Anderson wrote:
On Thu, 6 Jan 2011, Arne Vajh??j wrote:
On 06-01-2011 19:07, Lew wrote:
Midnightmare wrote:
Introduction of overload of operators, fuctional programming, parameters
passed by reference, safe and unsafe context, etc...
Operator overloading - unnecessary and confusing
Unnecessary for traditional business related programming.
Okay, you two guys either need to tell me about a language with
operator overloading in which you have extensive experience, which you
would require to make that statement, or retract that.
emacs is better than vi.
This topic is a language war a-brewing.
No, it is not - it is a discussion of a language feature. I would not for
a second suggest that any of C++, Python, or Ada were better than Java, or
the contrary. It is possible to discuss feature that some but not others
have without it being a language war.
I programmed extensively in C++ before working primarily in Java. So
there - plppppptttttthh! What a specious argument, tom.
It wasn't an argument, it was a question. I genuinely wondered if your
objection to operator overloading was rooted in not having used it.
I find operator overloading unnecessary - I really don't have any
trouble whatsoever with, for example, 'equals()'. I find no objective
basis to claim that 'equals()' is in any meaningful way "worse" than
'=='.
I'm not sure how to explain it to you. Use of == instead of equals() makes
expressions shorter, introduces a more visually distinct symbol for the
operation which makes it easier for the visual part of the brain to pick
it apart, and does not exacerbate parenthetic pileup, particularly at the
end of expressions - like:
if (candidate.equals(map.get(keyIterator.next()))) {
...
}
Being able to use == there would pull that line back from the brink of
requiring me to put my finger on the screen and count to get it right.
As for confusing, that is my own personal assessment of risk - I should
have said, "easily can be confusing". Other than for numeric types, for
example, there isn't a whole lot of naturalness to '+' as an operator.
(Not even for 'String', for which the operator is overloaded in Java.
I'm just as happy with, say, || as the concatenation operator
Fair enough. I'm not keen on || because it also means logical OR, which is
even less like concatenation than numeric addition is, but it's a small
difference. It would better yet if there was some other operator that
meant concatenation that wasn't already in use for something else - maybe
we can finally find a use for that ?? key.
and happier still with 'StringBuilder#append()'.)
Really? Wow.
Judicious use of operator overloading might make code marginally more
terse, and some people might find that clearer. Others not. YMMV.
These others - do you think they'd find it no clearer, or actually less
clear? If the former, that leave the use of operator overloading a net
positive. If the latter, i'd be interested to see an example - where
judicious use of operator overloading made code less clear to someone.
But operator overloaded is neither necessary nor sufficient for clear
code,
Certainly true!
nor is it unequivocally an improvement over what Java does now.
Yes, it is. It permits clearer, more concise code, and has no intrinsic
disadvantage.
Just because one personally likes it doesn't make it worth changing the
language for it.
Sadly true.
tom
--
All we need now is a little energon and a lotta luck
--232016332-1814140200-1294499690=:7448--