26 ms·
As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of
by sixbrx 10y ago
As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of the latest compiler just like it was in 2009:
$ scalac -version
Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc.
$ javap -private Rational
Compiled from "Rational.scala"
public class Rational {
private final scala.Tuple2 x$1;
private final int numer;
private final int denom;
public int numer();
public int denom();
private int gcd(int, int);
public Rational(int, int);
}
- paulddraper 10y agoSure, okay. But the point remains that "you couldn't have local/temporary variables in your class constructors" isn't quite true. FYI, you could avoid that but not without giving up `final`. This isn't exactly unusual. Lots of source languages (e.g., C) don't expose all the abilities of the target language (ASM). I'm surprised you mention this shortcoming compared to Java. I would have mentioned the lack of a Java enumeration equivalent.
- sixbrx 10y agoIt was short for the explanation in the following paragraphs (OK I should have added "without unwanted storage side effects" which was the whole point though). WHich I still haven't seen resolved in a memorable/non-gross way (I do assume extempore's hack works). Even Martin's private[this] idea from that thread was apparently never implemented, I just tried it also. I'm a Scala fan by the way, and this is a solvable problem (the private[this] solution would be fine I think). But it's currently a landmine IMO and an unfortunate because it's such an unforced error.