[jdom-interest] Re: First impressions and some suggestions

[Jason Hunter]

> >Elliotte, you're losing me here.  The code is this.
> >
> >String first = name.getChild("first").getContent();
> >String last = name.getChild("last").getContent();
> >
> 
> No, the problem code is this. What does
> 
> String fullName = name.getContent();
> 
> return? The "obvious" answer is "Alex Chaffee"; 

I disagree that's an obvious answer.  The getContent() method returns
the string content of an element.  I don't see how it's obvious that it
would take the string content from its children and append the strings
with a space in between.

> though that's not
> what JDOM is doing now or what it should do. My point is that the
> obvious answer isn't always the correct answer.

Isn't always, but can be.

> >behave the same, or not, for the common case of calling getContent().  I
> >think it should because that's what developers expect, and
> >getContent(true) can work for those relatively rare cases where you want
> >the whitespace.
> 
> I don't think these cases are rare. I think they're much more common
> than you expect.

I very much doubt these cases are the majority though, or even close to
it.

> I disagree that this API is fully spec compliant. I think you're
> telling me that you feel the XML spec is wrong; that white space
> should be less significant than XML 1.0 actually makes it. 

I don't disagree with the spec at all!  The spec writers realized that
some applications would require the surrounding whitespace, so they made
it clear that a parser couldn't ignore the whitespace and had to pass it
on; in other words, had to make it available to applications that needed
it.  That's exactly what we're doing!  The spec doesn't say,
"Surrounding whitespace must be available by a method with a shorter
signature than the method that returns non-surrounding whitespace." 
That's our decision.

> not some
> bowdlerized construct that's sort of like the content but not quite.
> If you want to provide a utility method so developers don't have to
> call trim(), then that's the one that should have a different name,
> something like getTrimmedContent() or getNormalizedContent().

Good, so you're willing to concede that it's OK to have two methods A
and B where one returns surrounding whitespace and one doesn't.  But,
somehow, you think it's spec non-compliant if the signature for trimmed
is longer than that for untrimmed, but compliant if the signature
lengths are reversed?  That doesn't make sense.  The XML spec doesn't
have any say over the signatures of A and B.  By your own logic, having
two methods (one for each behavior) is spec compliant, and whether we
use a boolean flag or different names to distinguish between the two is
a language and implementation detail and can't change spec
compatability.

-jh-