[jdom-interest] Comment and ProcessingInstruction parents

[Jason Hunter]

I think the reason it's like that is that there's getParent() and
getDocument() methods, and so if you're at the root level a
pi.getParent() will return null while a pi.getDocument() will give you
the containing document.

We use a single "parent" object to save space.  We used to have an
"Element parent" and a "Document doc".

I say punt on this for now, and let's look at Brad's "jdom-x"
Parent/Child interface proposal after b9.

-jh-

Elliotte Rusty Harold wrote:
> 
> I'm repeating this suggestion from April. At the time Bradley
> Huffman, agreed that it was a good idea. I don't think anyone else
> commented one way or the other. I've implemented this for Comment. It
> would be hard to implement it for the other classes.
> 
> The Comment and ProcessingInstruction classes appear to be deeply
> schizophrenic about who can be their parents, specifically whether or
> not a Document is allowed as a parent of one of these. (This is legal
> in normal XML temrinology. A typical xml-stylesheet processing
> instruction in the prolog would be considered to have the document
> itself as its parent.)
> 
> For example, in ProcessingInstruction the parent field is declared to
> have type Object:
> 
>     /** Parent element, document, or null if none */
>     protected Object parent;
> 
> However, setParent() and getParent() only allow elements as parents:
> 
>     /**
>      * <p>
>      * This will return the parent of this <code>ProcessingInstruction</code>.
>      *   If there is no parent, then this returns <code>null</code>.
>      * </p>
>      *
>      * @return parent of this <code>ProcessingInstruction</code>
>      */
>     public Element getParent() {
>         if (parent instanceof Element) {
>             return (Element) parent;
>         }
>         return null;
>     }
> 
>     /**
>      * <p>
>      * This will set the parent of this <code>ProcessingInstruction</code>.
>      * </p>
>      *
>      * @param parent <code>Element</code> to be new parent.
>      * @return this <code>ProcessingInstruction</code> modified.
>      */
>     protected ProcessingInstruction setParent(Element parent) {
>         this.parent = parent;
>         return this;
>     }
> 
> One of these needs to be fixed, and I think it's setParent() and
> getParent(). Processing instructions and comments do appear with the
> document itself as the natural parent. We need to support that.