[jdom-interest] Life or death of the Parent interface
Jason Hunter
jhunter at xquery.com
Fri Feb 20 12:02:55 PST 2004
So people seem to like the Content abstract class, but there's been some
pushback on the Parent interface. Some have suggested removing the
interface entirely. I'm wondering if that might be best.
Its main purpose right now could be described as a generic type for
setParent() to take and getParent() to return. There's also the benefit
when learning the API that you quickly see how Document and Element
share a core set of methods. Those benefits are nice, but really not
critical.
What people don't like is that now the various Parent methods --
addContent, setContent, getParent -- return Parent instead of the
specific Element or Document type on which they're acting. By removing
Parent we could fix that and simplify the API by one class. We'd just
change getParent/setParent to use Object. As another secondary perk, we
would avoid the Parent/Content odd naming convention.
In the end I don't think this is a critical design issue one way or the
other, but I'd like to make sure the situation is fully understood
before deciding.
Am I right in classifying the pros/cons of each proposal? Is the
biggest complaing about Parent how it reduces the ability to chain?
What about the lost ability to chain a getParent().getParent() sequence?
-jh-
More information about the jdom-interest
mailing list