Eric Smith schreef:
> I've written a class SPF to implement Dijkstra's Shortest Path First
> algorithm using bounded generics to allow the user to supply his own
[quoted text clipped - 16 lines]
> {
> public SPFVertex traverse (E edge);
Did you mean SPFVertex<E> here?
> }
>
[quoted text clipped - 27 lines]
> ^
> 1 error
You will get a warning about the traverse line as well.
> The problem seems to be that the SPFVertex traverse() method
> returns an SPFVirtex, which should be a V in class SPF, but for
> some reason the compiler doesn't think it matches.
Well, of course it doesn’t: traverse returns an SPFVertex<E>, but State
expects a subclass of it. It’s as if you would pass a Number to a
method which expects a Double. Not the same thing!
> If I put in an explicit cast to V:
>
[quoted text clipped - 11 lines]
> ^
> 1 warning
Well, yes, you could be casting a MyVertex<MyEdge> to a HisVertex<HisEdge>.
> I tried changing the return type of traverse to SPFVertex<E>, but
> that didn't eliminate the error.
You should do that anyway. Once you use generics, use them consistently!
> Can anyone explain why the result of the traverse() method is
> not being matched with V in class SPF?
I hope I did.
Now about a solution: I don’t see one at first. Do you really need
State to have a V? I.e., couldn’t you change State such that it stores
an SPFVertex<E>?
You could make Edges vertex-aware instead. But I didn’t get a nice
design out of that as well.
HTH, H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Piotr Kobzda - 08 May 2007 13:04 GMT
> Now about a solution: I don’t see one at first. Do you really need
> State to have a V? I.e., couldn’t you change State such that it stores
> an SPFVertex<E>?
>
> You could make Edges vertex-aware instead. But I didn’t get a nice
> design out of that as well.
Or make a vertices other vertices-aware. I.e. declare vertex as:
interface SPFVertex<V extends SPFVertex<V, E>,
E extends SPFEdge>
extends Iterable<E> {
public V traverse(E edge);
}
and SPF as:
public class SPF<V extends SPFVertex<V, E>,
E extends SPFEdge> { ...
piotr
Eric Smith - 08 May 2007 13:32 GMT
My class definition started with:
> public class SPF<V extends SPFVertex<E>,
> E extends SPFEdge>
> Well, of course it doesnʼt: traverse returns an SPFVertex<E>, but State
> expects a subclass of it.
OK, now I understand. Thanks!
> Do you really need
> State to have a V? I.e., couldnʼt you change State such that it stores
> an SPFVertex<E>?
Yes, changing it to an SPFVertex<E> solved the problem. In fact, I
did away with V entirely, and replaced it with SPFVertex<E> everywhere.
> You could make Edges vertex-aware instead. But I didnʼt get a nice
> design out of that as well.
I thought about that. I never did come up with a very good way to
make the edge object contain any smarts. All the logic wound up
in the vertex object, so the edge is really just a container for
the cost. Of course, the user may have more use for his edge object
unrelated to SPF. In my example code and puzzle solver code, it
is useful for the edge class (which implements SPFEdge) to have
references to the vertices. In particular, the constructors for the
edges automatically add the edge to one or both vertices (depending
on whether it is the edge subclass for a directed or undirected edge).
Only after I picked E and V to be my type parameters for edges and
vertices did I read the recommendation that E should be used for
elements and V for values. Now that I've done away with V, I
suppose I can claim that E does mean an element, which happens to be
an edge.
Thanks for the help!
Eric