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-

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@(protected)