diff options
author | Paul Phillips <paulp@improving.org> | 2010-12-20 23:34:20 +0000 |
---|---|---|
committer | Paul Phillips <paulp@improving.org> | 2010-12-20 23:34:20 +0000 |
commit | 3bfd81869ccffd0657a1b82eb483e0f26a283a46 (patch) | |
tree | 669c49e2d0d3302cb04b20dffe91c77292526306 /test/files/pos/seq-ordering.scala | |
parent | 3cfee5b1450a42c31a857c5dd10f68387d88e669 (diff) | |
download | scala-3bfd81869ccffd0657a1b82eb483e0f26a283a46.tar.gz scala-3bfd81869ccffd0657a1b82eb483e0f26a283a46.tar.bz2 scala-3bfd81869ccffd0657a1b82eb483e0f26a283a46.zip |
This commit is about not calling .length or .si...
This commit is about not calling .length or .size on Lists. Sometimes it
is unavoidable; not often. I created some methods for the compiler which
should probably be in the collections, which do things like test if two
sequences have the same length in a more efficient manner than calling
length on each.
Also, wouldn't it be wonderful to have some mechanism for finding these
issues in a more automated way. Like say an annotation:
LinearSeqLike {
@badjuju("Calling length on linear seqs is O(n)")
def length: Int = whee
}
Or since I imagine everyone thinks they're calling length with lists of
2 or 3, an optional runtime check which yelled if it sees you calling
length on a 600 element list, or worse:
var i = 0
while (i < myList.length) { // you don't want to see what this does
f(myList(i)) ; i += 1;
}
Uniformity of interface without uniformity of behavior leaves us with
traps. No review.
Diffstat (limited to 'test/files/pos/seq-ordering.scala')
0 files changed, 0 insertions, 0 deletions