Re: generics puzzle
On 10/20/11 7:14 AM, blmblm@myrealbox.com wrote:
In article<ZqDnq.5673$UK6.3114@newsfe06.iad>,
Daniel Pitts<newsgroup.nospam@virtualinfinity.net> wrote:
On 10/19/11 6:25 AM, blmblm@myrealbox.com wrote:
In article<M%hnq.3083$Oz5.1691@newsfe16.iad>,
Daniel Pitts<newsgroup.nospam@virtualinfinity.net> wrote:
On 10/18/11 2:45 AM, Steven Simpson wrote:
On 17/10/11 16:58, Daniel Pitts wrote:
On 10/17/11 5:14 AM, Steven Simpson wrote:
On 17/10/11 11:41, blmblm@myrealbox.com wrote:
One fix is to just introduce a method setFromModified() in GThing,
but that doesn't appeal to me.
Instead of adding it to GThing, create a static method:
private static<T> void setModified(GThing<T> t) {
t.set(t.modified());
}
What about the simpler solution:
in the GThing class:
public void setModified() {
set(modified());
}
It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
on it, but if I were the maintainer of GThing, I'd consider its
specification to be complete without this method. It doesn't increase
the value of the class as an abstraction. Adding it would certainly just
be a convenience for the caller. It solves a problem generated by the
design of the call site, not the design of the class's contract. The
caller can write his own routine as necessary.
Possibly, but if it is something that happens frequently, then it seems
more likely to belong to GThing than externally. Otherwise your
call-site is suffering from the code smell "feature envy"
One other approach is a "visitor" pattern:
I know the "visitor" pattern (vaguely anyway), but .... I'm not sure
I understand your version of it here, which -- does this compile?
because ....
public interface GThingVisitor {
<T> void visit(GThing<T> gThing);
};
(Aside: Hm, a generic method in an interface?! well, why not,
maybe, but I'm not sure it would have occurred to me to try!)
I've used it in the past, so I know it works.
public class SetModifiedGThingVisitor {
<T> void visit(GThing<T> gThing) {
gThing.set(gThing.modified());
}
}
Was this meant to implement GThingVisitor?
Indeed it was. This entire snippet was typed up in my mail program, so I
missed a few pieces.
public class GThing<T> {
public void accept(GThingVisitor visitor) {
visitor.accept(this);
}
}
visitor.visit(this)??
Yes, that's what I intended :-)
Typos (thinkos?) happen.
public class CallSite {
public void setAllModified(Iterable<? extends GThing<?>> things) {
GThingVisitor visitor = new SetModifiedGThingVisitor();
for (GThing<?> thing: things) {
thing.accept(visitor);
}
}
}
I can report that this approach works too, though I put the
visitor code directly in CallSite as an anonymous inner class
rather than writing a separate SetModifiedGThingVisitor class.
Overall this approach has for me a certain "can't quite get my head
around it" quality -- not in the sense that I don't understand how it
works, but in the sense that I can't quite sort out how it compares
to the static-method approach. Thoughts, anyone?
Frankly in this case it amounts to the same, but when you have more
complicated generics definitions, such as:
class A<T extends B<T, F>, F extends C<F, T>, Q extends D<T,F,B>> {
}
If you have an A<?, ?, ?>, I think the static approach fails due to
being unable to verify the "extends" part. Though I haven't tried it in
a while.