SAX: Stub interfaces to build a SAXReader parser from.

[ajvincent]

Please review the API only. There is no implementation yet.

[burner]

to be frank, IMO a class based sax/dom reader to D will go nowhere. People will want to pass function, delegates, you name it as callbacks. As a rule of thumb, avoid class as long as possible, and especially do not require people to use classes to use your api.

[ajvincent]

Are you saying that object-oriented programming is just a dead-end in D, or here specifically? (I'm asking because I'm genuinely confused. OO programming has been in my experience the goal, possibly to be superseded only by aspect-oriented programming, and this isn't that.)

I was following the SAX specification, and Mozilla's implementation, as closely as practical. The interfaces are intended to be callback containers, nothing more.

I'm not saying SAX is perfect - but look at how many callbacks we're dealing with here. There's elements, comments, CDATA, characters, whitespace, processing instructions, doctypes, XML errors, and all have to be handled. Do you really want one big function with over a dozen delegate arguments:

parseXML(in string source, in delegate startDocument(), in delegate endDocument(), in delegate startElement(in string namespaceURI, in string qName, in Attribute[] attrs), ...)

Or do you want one class that says:

setStartDocument(in delegate startDocument());
setStartElement(in delegate startElement(in string namespaceURI, in string qName, in Attribute[] attrs));
...
parse(in string source);

Or something else?

[burner]

Maybe I was not to clear. There is no api the D standard library that require you to implement some interface through classes.

The sketch you did at the end of your post is more in line with what I'm was thinking of. But without the forced use of delegates. Any maybe even range based

[ajvincent]

Canceling - I have a newer version of the file which I think is better.