Here is the proof:
vv.getRenderContext().setVertexLabelTransformer(MapTransformer.<Number,String>getInstance(
LazyMap.<Number,String>decorate(new HashMap<Number,String>(), new ToStringLabeller<Number>())));
Update: I’ve found a better example.
Here is the proof:
vv.getRenderContext().setVertexLabelTransformer(MapTransformer.<Number,String>getInstance(
LazyMap.<Number,String>decorate(new HashMap<Number,String>(), new ToStringLabeller<Number>())));
Update: I’ve found a better example.
Type inference!
Bah. They forgot to use Factory factories.
Thanks for the free publicity. I guess.
(That is to say: there are more constructive ways of expressing dissatisfaction of this sort. Especially with free code. Heck, some of them might even involve suggesting an alternative.)
Anyway, it’s not exactly clear what you’re objecting to. Certainly we could have split this up into several sequential statements with additional variables; this might make it more clear what was going on.
If instead you’re objecting to the use of the LazyMap-backed MapTransformer in place of using the ToStringLabeller directly, the pros and cons of this approach are as follows:
Con: More complex declaration, String labels cached by LazyMap could conceivably go stale (in another context, not in this one).
Pro: In cases in which toString() itself takes omega(1) time, this trades space for time by caching the labels so that repeated calls to toString() aren’t necessary.
On balance, using the ToStringLabeller directly in this case is probably the right answer.
As a side note, I’ve seen some of your proofs in topology on your other blog. And you’re calling _this_ proof that the world’s gone mad? :) (I’m not saying they’re evil; my topo is rusty and I only studied it informally anyway. But they’re certainly dense in spots.)
As for your second example, as far as I can tell, that causes problems iff you’re writing multithreaded code, and in particular iff you’re writing code in which you’re creating/using Contexts in separate threads. Can you construct an actual example in JUNG can bite you in this way?
The demo (with this seemingly endless string of generified commons-collections code) allows you to edit the labels for vertices and edges. The plugin to edit them checks to see if the vertex or edge LabelTransformer is a MapTransformer, and if so, puts your new value into the Map. If the vertex edge LabelTransformer were just the ToStringLabeller, that feature of the demo would not work.
Since it ‘has to be’ a MapTransformer, there needs to be a Map someplace.
The easiest way to populate that Map is with a LazyMap that uses the original ToStringLabeller.
Maybe this is not the best approach. I get caught up in the vastness of the commons-collections library. In any event, we welcome code and patches
Tom
(the guy who wrote the madness you quoted)
Believe it or not, the comment for the first example was more on how horrible such stuff is in Java than a criticism of the implementation – I understand the temptation to write such things very well, as I’ve done similar myself.
The second example is primarily a thread safety one, but I can conceive of situations where (if one were not aware of the potential issue) it can cause problems in single threaded environments when trying to combine multiple instances together (first thing that comes to mind is if one were trying to build a product graph and filter it based on filters on each of the components).
I’ll comment on potential improvements in the morning, as it’s latish over here. Suffice it to say, I fully intend to submit suggestions, and patches if you’ll take them. I was just slightly flabbergasted when I encountered this code and admittedly overreacted. Sorry for the slight lack of tact on my part. :-)
I remember how much I loved Java when it first appeared, like a breath of sweet-smelling fresh air after choking to death in the industrial smog of C++ (with all its templates and operator overloading and cast operators and other crap).
Generics and autoboxing, assertions and annotations, pattern factories and the bizarre assumption that XML is easier to write than Java code… excuse me while I go and vomit.
People will always want to tinker though, won’t they?
(with all its templates and operator overloading and cast operators and other crap).
And there was I thinking that these were the only things that made C++ palatable.
Pingback: Long Pointers » That Sucking Sound Is Java Killing Your Soul