L
Lawrence D'Oliveiro
The Python folks discovered this the hard way: providing a comparator
callback is slow. It’s better to provide a key-accessor callback, and let
the sort algorithm do the comparison.
The Python folks discovered this the hard way: providing a comparator
callback is slow. It’s better to provide a key-accessor callback, and let
the sort algorithm do the comparison.
T
Tom Anderson
Yes, and i tried not to think about it, because it's smelly. How do you
obtain these objects? Do you make them purely to use as key-holders? Does
that mean you're going to have half-filled-out instances of your value
class floating about the place? Does that mean you have to provide a
constructor that allows such instances to be created, so abandoning the
invariants that you could otherwise enforce through your constructors?
Or do you need to do something like:
public interface KeyHolder {
public String getKey();
}
public class Value implements KeyHolder {
private final String key;
// other fields
public String getKey() {
return key;
}
// other methods
}
public class Example implements KeyHolder { // so called for "query by example"
private final String key;
public Example(String key) {
this.key = key;
}
public String getKey() {
return key;
}
}
Map<KeyHolder, Value> objects = new TreeMap<KeyHolder, Value>(new Comparator<KeyHolder, KeyHolder>(){
public int compare(KeyHolder a, KeyHolder b) {
return a.getKey().compareTo(b.getKey());
}
});
Value v = ...;
String k = v.getKey();
objects.put(v, v);
Value u = objects.get(new Example(k));
assert u == v;
?
It can certainly be done, but all things considered, i lean towards
extracting the key before hitting the map. The map could perhaps be
wrapped in a simple wrapper:
public class ValueStore {
private Map<String, Value> map = new HashMap<String, Value>();
public void put(Value v) {
map.put(v.getKey(), v);
}
public Value get(String key) {
return map.get(key);
}
}
So that calling code is not troubled with the details.
tom
M
Mike Schilling
Tom Anderson said:
Simple use case that I've done several times:
I'm going to parse a file. For each keyword, I create an object that
describes how it should be processed; one of its fields is the string
representation of the keyword. I put it in a map using that field as the
key (map.put (kw.getName(), kw). Where do I get the String I'll use to look
it up? From reading the file.
T
Tom Anderson
Okay, crossed wires. If some type T has an embedded key K (ie there's some
method m such that you can say T t; K k = t.m()
, then you have twooptions. One, you can do what you describe there, and what i was also
talking about in my last post (with all the curly brackets), where you
have a Map<K, T>. Two, you can do what you described in your original
reply to Lawrence, and have a Map<T, T>, with a Comparator that says
compare(T a, T b) {return a.m().compareTo(b.m());}. Option two involves
using instances of T as keys. It's those instances which i was asking how
you obtain.
But perhaps the answer is that we use option one.
tom
M
Mike Schilling
Tom Anderson said:Okay, crossed wires. If some type T has an embedded key K (ie there's some
method m such that you can say T t; K k = t.m()
options. One, you can do what you describe there, and what i was also
talking about in my last post (with all the curly brackets), where you
have a Map<K, T>. Two, you can do what you described in your original
reply to Lawrence, and have a Map<T, T>, with a Comparator that says
compare(T a, T b) {return a.m().compareTo(b.m());}. Option two involves
using instances of T as keys. It's those instances which i was asking how
you obtain.
But perhaps the answer is that we use option one.
Fair point. This was simpler before generics, when the Comparator could
accept either K's or T's
L
Lew
Mike said:Fair point. This was simpler before generics, when the Comparator could accept
either K's [sic] or T's [sic]
Without further consideration I won't yet claim this is one of those times,
but sometimes simpler is not better.
The generics notion, with which I agree but others might not, is that the
complexity of generics buys you locked-down type assertions.
In the simpler way, you compare Ts and Ks willy-nilly, without really saying
so. Sure it works, but it's hidden.
With generics, you have to show the type relationship explicitly. This seems
consistent with Java's policy of dragging out every possible elucidation of
your algorithm, data structures and type structures at compile time without
regard for index-finger RMI. This is supposed to be good, both documenting
and enforcing the type analysis.
But the downside is that rigorous, explicit, very-carefully-thought-out and
thorough analysis is hard work. Work that professionals do anyway. Tough
programmers, tough on bugs. Hoo-rah!
B
blmblm
Mike said:Fair point. This was simpler before generics, when the Comparator could accept
either K's [sic] or T's [sic]
"[sic]"?
My understanding is that while it's less common than it used to be
to form the plurals of multiletter acronyms [*] with apostrophes
(e.g., "CDs" rather than "CD's"), apostrophes are still advised
for forming plurals of single letters, to avoid ambiguity in the
case of A and I (and possibly some others I'm not thinking of).
Can you cite any authoritative recommendation for leaving out
the apostrophes here?
[*] Or initialisms, for the pedantic?
[ snip ]
[ snip ]
L
Lew
Mike said:Fair point. This was simpler before generics, when the Comparator could accept
either K's [sic] or T's [sic]
"[sic]"?
My understanding is that while it's less common than it used to be
to form the plurals of multiletter acronyms [*] with apostrophes
(e.g., "CDs" rather than "CD's"), apostrophes are still advised
for forming plurals of single letters, to avoid ambiguity in the
case of A and I (and possibly some others I'm not thinking of).
But not "K" or "T".
<http://ethnicity.rutgers.edu/~jlynch/Writing/p.html#plural>
"Resist the urge to put an apostrophe before the s in a plural,
whether in common or proper nouns. The term for this vulgar error is
the “greengrocer's apostrophe,” ..."
<http://ethnicity.rutgers.edu/~jlynch/Writing/a.html#apostrophe>
"My preference: don't use apostrophes to make abbreviations plural —
not “They took their SAT's,” but “They took their SATs.” The only
exception is when having no apostrophe might be confusing: “Two As” is
ambiguous (it might be read as the word as); make it “Two A's.”"
Refer to his citations and C.V. for transitive authority.
L
Lew
Yes, it is a matter of style. Duh. That's why I cited a *style*
guide. There's a direct correlation there.
Yes, styles vary. The question was for *an* authority to support the
style I follow. As you say, some support what I suggest and some do
not. I follow the ones that do.
I don't follow every style, nor can one, given that they don't always
agree.
Personally I find the "greengrocer's comma" to distract and diminish
from the communication, so the style guide I follow concords with that
assessment.
YMMV.
T
Tom Anderson
In which case the use of 'sic' is dubious. You are not marking something
that is wrong, you are marking something that you wouldn't write that way
yourself. If you start doing that consistently, i think you will soon find
that your square bracket keys have worn out.
To be honest, the use of sic in quoted text in a mail or news post at all
is dubious. sic is used to indicate that there has been no error in
transcription; when it is a machine doing the transcription, it is
redundant.
tom
L
Lew
Blah, blah, blah, blah, blah ...
T
Tom Anderson
tom
B
blmblm
Mike Schilling wrote:
Fair point. This was simpler before generics, when the Comparator could accept
either K's [sic] or T's [sic]
"[sic]"?
My understanding is that while it's less common than it used to be
to form the plurals of multiletter acronyms [*] with apostrophes
(e.g., "CDs" rather than "CD's"), apostrophes are still advised
for forming plurals of single letters, to avoid ambiguity in the
case of A and I (and possibly some others I'm not thinking of).
But not "K" or "T".
Eh. I guess my thinking is that it's simpler to have one rule for
plurals of single letters, rather than having one rule for the ones
where there might be ambiguity and another rule for the others.
I don't agree, however, that using apostrophes to form plurals of
single letters is in this category of "vulgar error". Indeed,
your cited authority goes on to say that this is a matter of
"house style", and:
Anyway, thanks for the reply/citation. Very interesting.
I do think that if you're going to use [sic] at all in quoted
text -- which I'm inclined to dislike [*] -- it should be reserved
for egregious errors, not for matters of style. But whatever.
[*] Perhaps because to me any editing of quoted text, with the
exception of replacing words or phrases with "[ snip ]" or the
like, has unpleasant associations with a poster who shall remain
nameless.
J
Jerry Gerrone
No. None of the nasty things that you have said or implied about me
are at all true.