xml-dev - RE: org.xml.sax.ContentHandler conflicts with java.net.ContentHandler

["George T. Joseph" <gtj@peakin.com>]

Just because name conflicts already exist and will in the future doesn't make
creating new ones OK.  This API is still in beta and a name change is about as
easy as you can get.  Do it now and it will be forgotten in a week.  I've never
heard anyone say "Damn, we should have left those name conflicts in."

For the hell of it, I just went through the Xerces-J source and scanned for
XMLReader and ContentHandler.  30 seconds later, 7 affected source files were
identified and manually changed (no cheating with Perl scripts).  Another 15
seconds to change org.xml.sax, then 20 to recompile org.apache and org.xml.
Finally, 20 seconds to change and recompile my own code.  I suppose if I had to
check the code in and out of CVS it would have taken a little longer, but this
was not a big impact.

One ironic afternote...  The Xerces-J developers (a very bright bunch IMHO) use
the class-specific import style but in 3 of the 6 files in which
"ContentHandler" appears, it's only as "import org.xml.sax.ContentHandler" and
never actually referenced.  Gee, if it were "import org.xml.sax.*" maybe it
would have only taken me 15 seconds to identify and make the code changes
instead of 30.  For every plus there's usually a minus, isn't there?

george


-----Original Message-----
From: owner-xml-dev@xml.org [mailto:owner-xml-dev@xml.org]On Behalf Of
Jim Ancona
Sent: Friday, March 03, 2000 9:13 AM
To: xml-dev@xml.org
Subject: Re: org.xml.sax.ContentHandler conflicts with
java.net.ContentHan dler




--- Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
<<omitted>>
> Shouldn't we spare developers and students that pain if we can?

But we can't. If they don't hit the problem when using SAX they'll run
into it when using some other API. There are name conflicts even within
the Java core API's (java.util.Date and java.sql.Date come to mind).
SAX is a fairly low-level API. I wouldn't expect Java beginners to be
using it. Since it's unlikely that people will actually be USING
java.net.ContentHandler, the fix for the conflict is simple. (In
contrast, the Date conflict I mentioned above almost always requires
using fully qualified class names, because programs that use Dates and
JDBC typically deal with instances of both classes.)

> Even accepting that "import java.net.*" is bad form, doesn't absolve
> us of the responsibility to avoid the problem in the first place.

Whether importing an entire package is bad form isn't really relevant.
You can import both packages and avoid the conflict like this:

import java.net.*;
import org.xml.sax2.*;
// Avoid name clash with java.net.ContentHandler;
import org.xml.sax2.ContentHandler;

> Programmers have a real tendency to place blame where it doesn't
> belong. Most of the time that means that they blame "user error" for
> something their software could and should have detected and fixed.

I agree with this.

> Designing an API is the same issue, just removed back one step. We
> should blame programmers for using bad but legal and common style and

> thereby breaking our API, when we can design the API so they can't or

> won't make the mistake in the first place. Every potential error
> message we can remove, every source of confusion we can
> eliminate, is a good thing.

Name conflicts WILL occur. That why Java has packages, which provide a
mechanism for dealing with conflicts when they occur. Sooner or later,
anyone using Java for anything more than toy programs will run into the
issue, and will have to learn the solution. If you want to blame
someone for not focusing on user's needs in their design, you might
start with the person who wrote the javac error message you get when
the conflict occurs ("Class not found").

Jim


=====
Jim Ancona
jim@anconafamily.com                   jim.ancona@geac.com
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************