[jdom-interest] Another plea for Interfaces and other musings

[Paul Philion]

Alex -

Your argument applies just as easily to Vector and Hashtable. Perhaps if Sun
was really thinking about us programmers, they wouldn't have forced the
collection classes on us.

Further, the main reason that File is not a interface it that it already
relies on a native implementation of the package-private FileSystem class.
If File was an interface, it might make certain actions a little easier.

In my opinion, we really only need three interfaces: Document, Element and
Attribute. (Aside: The only reason we need Attribute is because it is formal
object, not just a method on Element.)

- Paul

PS: I just looked at Attribute again, in context of the recent thread on
"enhancing" Element with addContent(whatever). Attribute already supports a
whole array of methods like getDoubleValue() and getFloatValue(). What is
the reasoning behind that support in Attribute, but not in Element?

Personally I think that attribute values (and element contents) are
*strings*, and that any string-to-XXX facilities should be in their own
utility class. I wrote a "Value" utility class several years about that was
a bunch of static utility methods like Value.toInt(String) and
Value.toDate(String), etc., using the standard Java conversion methods. It
worked very well for me.

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Rosen, Alex
> Sent: Friday, March 16, 2001 1:30 PM
> To: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] Another plea for Interfaces and other
> musings
>
>
> Why doesn't java.io.File use interfaces? Why do we write...
>
>   File dir = new File(str);
>   File child = new File(dir, filename);
>
> ...instead of...
>
>   File dir = DefaultFileSystem.getInstance().createFile(str);
>   File child = dir.createChild(filename);
>
> ...?
>
> Because the former is clear, easy, and pleasant to write, while
> the latter is
> less so.
>
> I agree that interfaces would be more powerful, but I think we're all
> underestimating how much they decrease ease of use, and just the
> aesthetics of
> the API. JDOM was, as you said, created for easy reading and
> writing of XML.
> DOM is powerful and uses interfaces, so that niche is already
> covered. But DOM
> is really a pain to use for the 80% of the time when you just
> want to do the
> simple thing. JDOM's purpose is to fill that (large) niche. Maybe
> there's room
> for an API in between, that's more powerful than JDOM but easier
> to use than
> DOM, but there are probably several axes on which to define "more
> powerful", of
> which using interfaces is only one.
>
> I think it's great that JDOM doesn't use interfaces.
>
> --Alex
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhost.com