To really demonstrate autoboxing you need to allow the compiler to
convert from int to Integer:
Integer x = 1000;
Integer y = 1000;
However, if you are after interesting counterintuitive corner cases,
change the constant to 100:
Integer x = 100;
Integer y = 100;
A direct equality comparison will now compare true because, by default,
the JVM caches the Integer objects for values from -128 to +127 (the
range can be extended as an optimisation).
In other words, your corner case has a corner case. Magic.
Kevlin
On 2011-05-20 20:22, Martin C.Martin wrote:
John Daughtry brings up a much better example: autoboxing in Java. My
favourite corner case:
Integer x = new Integer(1000);
Integer y = new Integer(1000);
x < y // Compares the underlying integers: false
x > y // Compares the underlying integers: false
x == y // Compares the two objects: false
Best,
Martin
-------- Original Message --------
Subject: Re: "Magic" features of programming languages
Date: Fri, 20 May 2011 12:31:53 -0400
From: John Daughtry <j...@daughtryhome.com>
To: Martin C.Martin <mar...@martincmartin.com>
I don't have a reference, but a more general example...
A great well-known example of this problem being introduced to a
language is auto-boxing in Java
... and the problems it creates when combined with the collections
classes. Bloch outlines this in detail in Java Puzzlers. Why doesn't
this work?
1 myList.add(10); //we now have {10}
2 myList.add(1); //we now have {10,1}
3 myList.remove(1); //we now have {1} but we expected {10}
Line 1 uses autoboxing to invoke the method add(Object) while line 3
just calls remove(int).
The "magic", once combined with other features, turned into an
unintuitive mess. It gets even crazier
John
On Fri, May 20, 2011 at 11:46 AM, Martin C.Martin
<mar...@martincmartin.com <mailto:mar...@martincmartin.com>> wrote:
Hi all,
When a construct is ambiguous, sometimes language designers will
provide a default which (they hope) does the right thing in the
common case. An example is XPath. When = is called on two sets,
the semantics are that there is at least one pair of elements (one
from each set) that compare equal, i.e. that their intersection is
non-empty.
This is arguably counter-intuitive. For example, if an XML node
represents an item from a catalog that comes in multiple colors, and
you ask whether item1.color = item2.color, in some situations you'd
be surprised that {Red, Green, Blue} was considered the same as
{Red, Yellow}. Other times it's natural, e.g. when you want all
items that come in Red.
I have a hunch that, when a concept is genuinely ambiguous,
providing a default leads to "copy-and-paste" programming where
programmers don't really understand how a feature works, so they
just use it in a few canonical forms. Even though there is a simple
semantics that's easy to describe, they won't find that semantics
unless they look in the manual, and many people don't. Instead,
they just think it's magic and become confused when they try to do
complicated things with it.
Have there been any studies that include a look at such "magic"
features? Scripting languages typically favor conciseness, and thus
can have a fair bit of "magic."
Thanks,
Martin
--
The Open University is incorporated by Royal Charter (RC 000391), an
exempt charity in England & Wales and a charity registered in
Scotland (SC 038302).
--
________________________
Kevlin Henney
+44 7801 073 508
http://curbralan.com
http://kevlin.tel
________________________
