Re: Java 7 features
On Jul 3, 7:40 am, julien.robins...@gmail.com wrote:
switch: runs through all cases comparing with the operator "==". May
accept null, and probably useless for strings.
Interning the strings makes them viable here.
switch-equals:
uses "equals()" to test each case. Requires passing an object (or uses
auto-boxing?).
It could not accept null pointers, even though I would favor:
"switch (x) {case y:" should be exactly the same behavior as
"y.equals(x)"
so that x may be null
If ever some y is null, throw NullPointerException of course. :-)
and if x is null, of course it switches to default.
Why not allow null anywhere? Null is unequal to anything but null,
unless some object's ".equals(null)" returns true for whatever reason.
My own recommendation is to make switch use == on primitive
types, .equals on reference types, and give a warning when floats or
doubles are compared.
switch (primitive) {
case x:
....1
case y:
....2
break;
default:
....3
}
is made syntactic sugar for
if (x == primitive) {
....1
....2
} else if (y == primitive) {
....2
} else {
....3
}
for instance.
With a nonprimitive, you get
switch (object) {
case x:
....1
break;
case null:
....2
break;
default:
....3
}
turning into
if (object == null) {
....2
} else if (object.equals(x)) {
....1
} else {
....3
}
say. (Always the test for == null occurring first, with either the
appropriate case block or the default block's code, followed by any
others.)
But I've also got a good suggestion for any operator overloading.
Firstly, binary operators between reference types are allowed if both
compile-time types have a common superclass or implement a common
interface that specifies the corresponding method (including if the
compile-time types of both sides are equal and this type specifies the
appropriate method).
Secondly, operators are then just syntactic sugar as follows:
-x -> x.negate()
x + y -> x.add(y)
x - y -> x.subtract(y)
x * y -> x.multiply(y)
x / y -> x.divide(y)
x += y -> x = x.add(y)
++x -> x = x.increment() (and add this method to BigFoo; it returns a
new instance, representing a value one higher)
x++ -> (t = x, x = x.increment(), t)
--x and x-- analogously with a decrement() method
x ~= y -> x.equals(y) (a whole new operator; if ~= allowed for
primitive types it behaves the same as == for these)
!x (maybe allow as shorthand for x == null)
(various bitwise operators should correspond to their BigInteger
methods)
A key thing is that the implied method is always invoked on the left-
hand operand, with the right-hand operand (if any) as method argument.
This means that operators would be polymorphic only on the first
argument. Using double-dispatching or other patterns when implementing
your add, subtract, multiply, etc. methods in your own class hierarchy
would be able to give the benefits of bilateral polymorphism, of
course.
It would be desirable to be able to set a thread-local MathContext for
BigDecimal calculations and scope it somehow. I'd suggest a more
general "environment" or "context" mechanism built on a (hopefully
speeded-up!) threadlocal mechanism, whereby you can use code like
do switch (threadlocal: expression) { ... stuff ... }
(which overloads, unambiguously, existing keywords) to:
* Save the current value of the thread local somewhere
* Change it to "expression".
* Stuff
* Restore the old value of the thread local
It would be syntactic sugar for:
Object t3dsfgr838 = someThreadLocal.get();
someThreadLocal.set(expression);
try {
stuff
} finally {
someThreadLocal.set(t3dsfgr838);
}
where the temporary's name is guaranteed not to otherwise exist in
this scope.
There should then of course be built-in thread locals for some stuff
(such as math context to use for the forms of BigDecimal methods that
don't take an explicit one, and which overloaded + and the like would
use). Switching on a particular math context for a block of
calculations is then easy and natural:
do switch (Math.mathContext: myMathContext) {
someBigDecimal = someOther + yetAnother;
someBigDecimal *= 4; // Should accept mixed primitive/reference
// types IF the reference type has a valueOf(foo) method
// matching the primitive to use for promotion!
someMoreCalculations();
}
And of course ThreadLocal should be made a) faster to access (at least
to just read) and b) generic (so with a ThreadLocal<String>, you would
not have to cast theThreadLocal.get() to String, etc.; why was this
done promptly for WeakReference et. al. but not ThreadLocal? Arrrgh!)