xml-dev - Re: org.xml.sax.ContentHandler conflicts with java.net.ContentHan dler

[Elliotte Rusty Harold <elharo@metalab.unc.edu>]

At 10:05 AM -0500 3/1/00, David Megginson wrote:
>
>Thanks for the support.  I've always considered import package.* to be
>the sign of either
>
>a) a novice (forgivable); or
>b) expremely sloppy coding.

I'm not sure I understand the objections to this style. Certainly 
it's prevalent. I used the single class import in my first book, but 
went back to import java.net.* after that to save space and time. It 
seemed to me that nothing was really gained by using the shorter 
format, and I almost always left out a few classes and ended up 
having to recompile at least once because I forgot to import a class. 
But I think there's a more serious objection to this response as I'll 
explain below.

>
>
>I understand the concerns with both XMLReader and ContentHandler, but
>I'm very reluctant to make changes this late in the SAX2 process, and
>we've already spent a lot of time discussing the XMLReader name.  Do
>people feel very strongly about renaming either of these?
>

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?

This name promises to waste a lot of time for lots of programmers. We 
can fix the problem here, once and for all, with a few hours of our 
time and thereby save thousands of hours of productivity for the 
developer community in the future. It's a wise investment to make.

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


+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

***************************************************************************
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/threads.html
***************************************************************************