switch using strings

[Tom Anderson]

Not and kept it immutable. I’d probably have outlawed ++, +=, etc.

+1

Alternatively, i might do what Python does, and define a += b as shorthand
for a = a + b. Then ++a as a = a + 1.

tom

 

[Michael Wojcik]

Now, instead of piling on me like a rugby scrum, folks, consider if I'm
asking people to do something prudent or foolish. "Be careful,
autoboxing is dangerous." That communicates advice to research (why
should I suddenly be Professor Proof for all you lazy jerks?) and
*decide for yourself* what the limits of autoboxing are so that you are
not surprised.

I thought it was a pretty reasonable pronouncement. I understand Eric
Sosman's objection to labeling it a "fact", but here in the realm of
what some philosophers call "informal logic" (we're not writing law
here, or mathematical proofs, or the next revision of the JLS) that
didn't strike me as too great a leap either.

But then I suppose I'm inclined to agree with you on this point
anyway. I don't recall ever wanting to use a Java feature from after
J2SE 5. Once in a while proper closures would be more elegant than
anonymous inner classes, but in those cases there's generally some
solution that's more readable than either.

(If I really want closures, I can work in Scheme, or OCaml, or F#, or
any of the other dozens of functional languages I have lying around.
Or Clojure, I suppose, if I want to target the JVM. No need to make
Java be everything.)

 

[Arne Vajhøj]

You are absolutely correct. The example was trivial, not tied to
autoboxing particularly, and perfectly scaled for someone who was
apparently unwilling to do the research.

And certainly started a conversation that led to all sorts of useful
links, concrete and much, much better examples than mine, and hours of
entertainment. Oh, and utter vindication of my original, overstated point:

Autoboxing isn't all that useful. It has dangers. I prefer not to use it.

But why?

When the feature is in the language then you got the risk even if
you don't want the benefits.

Arne

 

[Arne Vajhøj]

Eric Sosman wrote:
Re-write the code without auto-boxing/unboxing -- pretend you're
using a pre-1.5 Java -- and I'm sure you'll see the problem. (And
since you didn't see it right away, I think that lends support to the
notion that autoboxing is, or at any rate can be, "dangerous.")

That's just your opinion.

... and marked as such by the phrase "I think."[*] I lack the
arrogance to propound my opinions as "facts."

:-(

[*] René Descartes walks into a bar, and the bartender asks "The
usual?" Descartes says "I think not," and poof! he disappeared!

And I lack the political correctness to present facts as mere opinion.

I am not sure that distinguishing between objective facts and
personal opinions is PC.

Arne

 

[Arne Vajhøj]

That was uncalled-for.

I would say that your signature calls for it.

Arne

 

[Arne Vajhøj]

There is nothing about "strange" or "surprising" in the definition of
"danger", just risk of harm. NPE is harm. Misuse of autoboxing can
cause that harm. Ergo, autoboxing is dangerous.

http://www.merriam-webster.com/dictionary/danger?show=0&t=1299099462

Most language features are dangerous in some way or
another.

That feature X is dangerous is not in itself a problem.

It is a problem if it is likely that the potential will result
in harm given average programmers and normal code *or* if the
benefits are so small that they do not justify the added risk.

Arne

 

[Arne Vajhøj]

(If I really want closures, I can work in Scheme, or OCaml, or F#, or
any of the other dozens of functional languages I have lying around.
Or Clojure, I suppose, if I want to target the JVM. No need to make
Java be everything.)

I suspect that it is very dangerous (!) for a language to attempt
to be good at everything.

Arne

 

[javax.swing.JSnarker]

On 3/3/11 9:46 AM, javax.swing.JSnarker wrote:
[...]
Some language features make it easier to do than others.

So?

So, that is the entire point of this discussion. Many programmers prefer
to avoid the use of language features when those language features offer
an above-average probability of writing code that looks correct but
which is not.

But where do you draw the line?

How is it that you don't already know the answer to that question? I
have already made clear statements explaining my position.

It was a rhetorical question. It's clear where many of us, individually,
draw the line, but some of you seem to be arguing as if there's a
general procedure for drawing the line and all of us who use another are
wrong.

As I already told you, Java does not allow that. You even quoted the
relevant part of my post

I hadn't reached that part of your post yet at that point.

C# doesn't have special auto-boxing destination types. Boxing of value
types always results in a reference to an object typed as System.Object.

What, there aren't separate Integer, etc. types? Or boxed integers,
floats, etc. all are treated as Object and require an explicit cast? Why
was this done and how does this help anything? If the latter, if you
declared a method as accepting Integers and called it with literal 42 it
wouldn't work because 42 could only be either int or Object!

More to the point, no matter what one tries to do by way of preventing
this error, the type presented to the "synchronized" statement can
always be made to be simply java.lang.Object, regardless of where that
object comes from. You can always turn the wrong thing into
java.lang.Object with a cast. So any compile-time restrictions are never
going to be more than just "rule of thumb" kinds of restrictions; it is
not literally possible for the compiler to _prevent_ these errors. It
can only make them more difficult.

Perhaps it should issue a *warning* when the type is a boxed-primitive
type, since it seems it shouldn't quite be an *error*.

While I feel it's poor practice to use "this" or other exposed
references for synchronization, _that_ is clearly not something the
language designers are concerned about and in fact clearly feel it
should be allowed. Given that, then to impose other kinds of syntactic
restrictions on the "synchronized" statement does little to _really_
prevent these errors from occuring; it just complicates the language
specification and the compiler, while forcing the inept and
inexperienced programmers to add casts to their code in order to make
their mistakes.

One wonders why there wasn't a specific Lock type whose sole purpose was
to be used in synchronized and which had the wait and notify methods?
This would have reduced the overhead that all Objects currently carry.

Water under the bridge now, of course ...

Sorry if I did not make my point clear. There are reasons for
immutability independent of auto-boxing. _Those_ reasons remain the
same.

They don't apply to the hypothetical creation of a different type for
autoboxing though.

public class Paraphrase
{
int counter = 0;
Object lock = new Object();

public void increment
{
synchronized (lock)
{
counter++;
}
}
}

Okay, though the relationship between the lock and the counter is not
made explicit by naming (in a hypothetical much more complex class
containing those members).

Please go back an re-read the text.

Excuse me? How rude. I read it and comprehended it just fine the first time.

We were specifically discussing Integer and "hypothetical new integer
types", _not_ AtomicInteger.

Wrong -- I was specifically suggesting overloading ++ and the like for
AtomicInteger to make that class more convenient to use. If you didn't
understand it as such, that's not my problem.

Second, by your reasoning, hypothetical new operator overloads have no
bearing on the discussion, making your entire line of reasoning irrelevant.

Non sequitur.

How in the world did you find the statement "Or an 'int' instead of an
'Integer'" to be argumentative?

Not just that statement; your general attitude expressed in your several
recent posts to this thread.

Get a grip.

Gratuitous rudeness on your part.

 

[javax.swing.JSnarker]

I would say that your signature calls for it.

What does your classic unsubstantiated and erroneous claim have to do
with Java, Vajhøj?

 

[Mike Schilling]

Java could have take a related (but not precisely the same) approach by
prohibiting the use of _boxed_ value types (e.g. java.lang.Integer) in a
"synchronized" statement. It already requires the expression in the
"synchronized" statement to be a reference, refusing to auto-box in the
same way that C# does. But it also could prohibit auto-box destination
types, such as java.lang.Integer.

But those were allowed before autoboxing, so that would break existing code.

 

[javax.swing.JSnarker]

[...]
Gratuitous rudeness on your part.

Um, it seems that your snarky predilection has left you a bit paranoid
about the motivations and behaviors of others.

For the record, I said the above in response to you saying "get a grip",
which is generally considered to be rude behavior for it implies that
one's interlocutor is panicking, insane, or similarly. Of course, so
does saying he's "a bit paranoid" ...

 

[Arne Vajhøj]

What does your classic unsubstantiated and erroneous claim have to do
with Java, Vajhøj?

You brought up the topic of behavior so you tell us how
it is relevant.

And it is very substantiated - everyone can read your signature.

Arne

 

[javax.swing.JSnarker]

And it is very substantiated - everyone can read your signature.

But my signature doesn't justify namecalling from you in response to a
post I made that didn't have anything whatsoever to do with you.

 

[Jerry Gerrone]

Um, it seems that your snarky predilection has left you a bit [insult
deleted].  If you're going to go all Twisted/Jerry/Ken on me, [implied
insult deleted].

None of the nasty things that you have said or implied about me are at
all true. Ken and JSnarker can speak up in their own defense if they
wish. You, on the other hand, can shut up.

Good day.

 

[Lew]

Now where have I heard that before?

Nobody says anything nasty about "Jerry Gerrone" because we don't know who he
is. We're all just a pack of cards. Let's just leave him alone.

He doesn't need to be nice to us. He just needs to be nice to children and
small animals, and a gentleman in the presence of the fairer sex. If he does
those things, he can say anything else he wants.

"Jerry Gerrone" is a good person, whoever he is.