Robert Klemme <shortcutter@googlemail.com> wrote:
On 30.08.2012 23:55, Andreas Leitgeb wrote:
Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:
Or, if you know all the keys before hand, you can use instead
Map<Long,MyLongWrapper> map.
MyLongWrapper would have .set() and .get(), or even .actUpon()
depending on the semantics you need.
My code now looks essentially like this: (containing class omitted)
void doSomething() {
// Val could be a static nested or a toplevel class, as well
// I've got it here for local context. I'd separate it out
// only if profiling results suggested doing so. ;-)
final class Val {
private long val=0; long getVal() { return val; }
void actUpon(long arg) { val = some_formula_on_val_and_arg; }
}
Map<Long,Val> map = new HashMap<Long,Val>()
for (Long key : listOfInterestingKeys) { map.put(key,new Val()); }
// the main iteration: (each foo has two keys and a value)
for (Foo foo : fooCollection) { Val fw;
fw=map.get( foo.key1 ); if (fw != null) fw.actUpon(foo.value);
fw=map.get( foo.key2 ); if (fw != null) fw.actUpon(foo.value);
// plus some more stuff using also the "uninteresting" keys.
}
for (Map.Entry<Long,Val> me : map.entrySet() ) {
doSomething(me.getKey(),me.getValue().getVal());
}
}
Again: thanks, Daniel Pitts, for pointing me the right direction
with a mutable value-wrapper class, instead of some Entry-alike!
containsKey() is unnecessary work. Just get(), and if it's null [...]
Was indeed. And my action for null happened to be "ignore".
Btw, if you use long as member instead of Long then you do not even
necessarily have more objects.
While that happened to apply to my case, it wasn't really a primary concern.
null, and sometimes that just doesn't make any sense semantically. The