Re: [xml-dev] DOM's javascript roots (was Re: [xml-dev] Have JDOM / XOM

[Robin Berjon <robin.berjon@expway.fr>]

On Mar 31, 2006, at 21:04, Elliotte Harold wrote:
> Robin Berjon wrote:
> > No, I don't think that's true. If the DOM had been created for  
> > Javascript it would be a *lot* less horrible than all the hoops it  
> > had to jump through to support utterly braindead languages like Java.
>
> The mistake was not anyone language's. It was trying to be all  
> things to all languages. That approach is doomed to failure.

I beg to differ. I've looked at XOM, and while I see it improving on  
the elegance of the interface -- which isn't something that's going  
to convince that many folks in the field -- and some niceties, the  
pain level in using it doesn't feel all that much better, at least  
not sufficient to justify learning something new. I'm not saying it's  
bad, just that you seem to have hit the limits of what can be done  
simply.

Do you have an example of something in the DOM that hurts Java that  
was obviously done so that Javascript would work? In the other  
direction, you don't need to look any further than NodeList (not even  
counting the liveness).

> > The reason alternatives to the DOM have not been all that  
> > successful for Java is because Java is all about cargo-culting and  
> > pain. Cargo-culting as in you throw IO exceptions when you write  
> > to memory, because it looks like what the other guys are doing (I  
> > don't even count those anymore), so if other folks are using the  
> > DOM you use the same, none of that crazy new stuff can possibly be  
> > any good. Pain as in if you've resigned yourself to need seven  
> > lines of code to open a text file for writing,
>
> FileWriter out = new FileWriter("filename.txt");
>
> One line. What's so hard about that? Of course you can make it more  
> complex if you like. You'd probably want to do that in order avoid  
> assumptions about  file system conventions, character encodings,  
> current working directories, and the like. However you need to do  
> that in Perl, Python, etc. as well.

Is it only that? If I just type that in, I get "Unreported exception  
IOException...". So I fix it thus:

try {
  FileWriter out = new FileWriter("filename.txt");
}
catch (Exception e) {}

That silences the issue. Admittedly, I'm not doing anything with the  
exception, in fact I'm silencing it completely. Surely you'll agree  
that's very bad practice. I should at least report it to the console  
or throw a runtime exception or something:

try {
  FileWriter out = new FileWriter("filename.txt");
}
catch (IOException e) {
  System.out.println("something bad happened" + e.getMessage());
}

We're at six lines, though of course I guess you could compress it a  
bit if you really wanted to.

But now I'm writing in my platform's default encoding. That might  
have been tolerable in the 80s when the folks who came up with this  
ridiculous API were sharpening their text-munging fu on ASCII, but  
those benighted days are thankfully over, in no little part thanks to  
XML's arrival.

Surely there must be a way to handle that at the FileWriter level.  
Oh, wait, no, there isn't. So this class designed to write "character  
files" actually can't write characters in any useful way. I'll have  
to configure an object to know how to write UTF-8, and then pass that  
to something else that might just write to a file. I'd give the code  
but there's beer waiting, and there's little point in rubbing it in.

I could go on, talk about IOExceptions in ByteArrayOutputStream and  
many other friends, but you get the idea. And to say that all I  
wanted to do was:

  open my $fileHandle, ">utf-8", "filename.txt" or die "Error  
opening file: $!";

Seriously though, I'm not here for language bashing. If I'm ready to  
put up with the above aggravation, why would I care about the DOM  
using interfaces vs classes, or live lists vs dead ones? If writing  
simple text to a file is already a major hassle, why should I expect  
manipulating an XML document to be easier? I'm not saying that people  
shouldn't be using simpler Java APIs, just that I can't see why  
they'd even think that it might be possible in the first place.

--
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/