[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: org.xml.sax.ContentHandler conflicts with java.net.ContentHandler
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@x... [mailto:owner-xml-dev@x...]On Behalf Of Jim Ancona Sent: Friday, March 03, 2000 9:13 AM To: xml-dev@x... Subject: Re: org.xml.sax.ContentHandler conflicts with java.net.ContentHan dler --- Elliotte Rusty Harold <elharo@m...> 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@a... jim.ancona@g... __________________________________________________ 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@x...&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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|