Re: Generics headache
On Sun, 27 Jul 2008, Lew wrote:
Leonardo Teixeira Passos wrote:
In the presented code fragment (made just to present the problem, as
faithfully as the original one), yes, the type variable is not necessary,
but in the real code it is perfectly suitable and needed.
In case you are curious, feel free to browse the code in the CVS browser
for dcompframework, a SourceForge project. Comments are always welcome :)
My comments were based on the SourceForge source. I downloaded the whole
thing and set up a NetBeans project.
This is the code from the SourceForge version:
public abstract class Parser<ParserMatchingType> {
abstract public AST parse( Scanner scanner,
Map<String, LinkedList<String>> parameters )
throws Exception, ParseException, ScanException ;
public void doAfterEachMatch( ParserMatchingType value,
Map<String, LinkedList<String>> parameters ) {
/* By default do not do anything. */
}
}
The 'parse()' method makes no use of the type parameter 'ParserMatchingType'.
No, but doAfterEachMatch does. I guess what you're saying is that the
parse method is the key element of the Parser, so if that doesn't need to
know about a ParserMatchingType, then Parser shouldn't either. I don't
know enough about the system to make that judgement - are you saying that
based on a deeper understanding, or a point of principle?
I'm curious as to how you'd refactor here to eliminate the type variable.
Presumably, you wouldn't just make doAfterEachMatch take Object for a
value. Would you factor out a subclass
PostMatchActionParser<ParserMatchingType>, and push the method down to
that?
I'm also suspicious about ParserMatchingType not being involved in the
parse method. What does ParserMatchingType actually mean? My gut says that
it's the type of whatever the parser is extracting from its input text,
and that the doAfterEachMatch method is a template method by which
subclasses of some particular parser can get a hook to do some action
after each one has been matched. However, my gut also says that these
values are being put in the AST tree which is returned. If you read the
AST classes, there's no mention of a value, but then ASTNode is abstract,
which suggests that the value will be handled in subclasses. My gut
suspects that you may want to parameterise AST and ASTNode with
ParserMatchingType, and have a method ParserMatchingType getValue() or
similar on ASTNode. My gut thinks that method is defined in subclasses
anyway, with an exact, non-generic return type, in which case it should be
pulled up to the base class.
That said, my gut is only a gut, not a brain, so it could be completely
wrong.
tom
--
an optical recording release. copyright digitally mastered. .,