[jdom-interest] Re: Factories for Element creation

[Thomas Koch]

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 11/3/00, 9:07:40 PM, Elliotte Rusty Harold <elharo at metalab.unc.edu> 
wrote regarding Re: [jdom-interest] Re: Factories for Element creation:

[...]
> >However, we have encountered one problem when subclassing Element:
> >the final toString() method (which we would like to override).
> >Is there a chance to change that?
> >

> We originally made it final to prevent people from using it instead
> of getSerializedForm(). toString() is for debugging only.

> Here's my question to you: why do you want to subclass it? What's
> wrong with the existing behavior? What use-case do you have for which
> the current implementation of toString() fails you? What do you want
> to change about this method?
> --

The subclassing of Element is done to provide e.g. tag-specific state
and, as in my case, to support additional interfaces. This approach was
discussed earlier in this thread. 

Restricting toString() to debugging creates a potential problem with 
respect
to the documentation of Object.toString(), which states:

"Returns a string representation of the object. In general, the toString
method returns a string that "textually represents" this object. The 
result
should be a concise but informative representation that is easy for a 
person
to read. It is recommended that all subclasses override this method."

It seems that various packages rely on this, including core Java 
packages.
Unfortunately, some of those interfaces we are implementing do define
the toString() method (for valid reasons, including debugging), and 
we can't change those. The intention is not to produce a mockup XML 
string, 
but rather a readable representation of the state of the subtyped object
that is displayed/printed as a text etc. I agree that toString() should
not generate an XML fragment.

Thomas