Re: Generics Issue
Lew wrote:
All I needed to parametrize on in my SSCCE was the "T extends
DataObject", which I renamed "Modeler" since "Object" in an object's
name is redundant and "Data" is too wide a concept.
Whereas Modeler is merely meaningless (and misspelled)? :)
Neither:
<http://en.wiktionary.org/wiki/modeler>
As you say, it needs to look only at ErrorRule<T> internally. (Not "=
?
super T", though, at least not the way I did it.) This seems consist=
ent
with the original intent.
The SSCCE I provided seems to cover the OP's concerns, AFAICT. Go
with the version where I remarked:
I eliminated the initialization override. This protects against the
method being called again, say by a malicious subclass.
I believe you mean this one:
http://groups.google.co.uk/group/comp.lang.java.programmer/msg/b0908c...
Yes.
I have to confess that i only skim-read it when i first saw it.
Oh, well. It was totally fun for me - a true generics puzzler. I
learned a lot from writing it.
A minor aside - as it is, i can't compile it; i get;
Cavett.java:67: method does not override a method from its superclass
@Override
^
Cavett.java:79: method does not override a method from its superclass
@Override
^
2 errors
I think it's the annotation.
I'm on 1.5.0_13; are you on 1.6, and is this something that's changed
between them?
I wouldn't have thought so, but I think they changed @Override to
apply to interfaces as well as classes. Try refactoring the
interfaces as abstract classes; if that makes the error go away then
you're on to something.
Java 5 is in End-of-Life phase, so you might want to move to the
current version anyway.
Anyway, having had a look at it, i agree with you - that's exactly what i
was thinking.
My point was really about this bit:
public static void main( String[] args )
{
ErrorSuite <TestModeler> suite = new TestErrorSuite=
();
suite.verify( new TestModeler() {} );
}
The calling code needs to mention the type of Modeler that's being tested=
..
This is absolutely unavoidable if you want type safety, as this is where
the creation of the ErrorSuite and Modeler occur, and the two need to be
tied together in terms of type. I think the OP was hoping to be able to
get away without this, but to still have type safety.
I agree, one must tie things together somehow, but I just don't see
this as a very narrow restriction. If an ErrorSuite intends to deal
with any old Modeler then the Rule has to be able to accept any old
Modeler; you cannot restrict the Rule more than the ErrorSuite. The
type-safety concerns mirror the logical decomposition of the problem.
Originally, i was thinking there was a hack you could do with Class.cast(=
)
that would push some of the typechecking to runtime, and sort of let you
get away with a non-generic TestModeler, but i couldn't work out anything
useful.
I like the compile-time safety more than run-time.
--
Lew