[
Lists Home |
Date Index |
Thread Index
]
- From: Jim Ancona <scarhill@yahoo.com>
- To: xml-dev@xml.org
- Date: Fri, 3 Mar 2000 06:12:50 -0800 (PST)
--- Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
> I do, especially about ContentHandler. This list is full of fairly
> experienced Java programmers who won't have a great deal of trouble
> with this. However, I don't think we're representative of the users
> of this API. I know from students in my classes and reader email that
> even a simple deprecation warning throws a lot of people for a loop.
> The error message about the name conflict with ContentHandler is
> going to be completely incomprehensible to a lot of people. They'll
> figure it out eventually, but it won't be a 30-second fix like it is
> for most of the people on this list. It will take them hours of
> painful debugging and guessing and testing to track this one down.
> 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/
***************************************************************************
|
