Daniel Keep wrote:
Andrei Alexandrescu wrote:
It would be great if you could contribute to Phobos. Two things I hope
from any replacement (a) works with ranges and ideally outputs ranges,
(b) uses alias functions instead of delegates if necessary.
There's really only one sane way to map XML parsing to ranges: pull
parsing, which is more or less already a range. For those unfamiliar
with it, this is how you use Tango's pull parser right now:
[snip]
This would fairly naturally map to a range of parsing events and look
something like:
foreach( event ; new PullParser!(char)(xmlSource) )
{
switch( event.type )
{
/* again with the cases */
}
}
Looks great. The network I/O could run separately too, in a
consumer/producer fasion.
Of course, most people HATE this method because it requires you to write
mountains of boilerplate code. Pity, then, it's also the fastest and
most flexible. :P (It's a pity D doesn't have extension methods since
then you could probably do something along the lines of LINQ to make the
whole thing utterly painless... but then, I've given up on waiting for
that.)
This is basically the only way to map xml parsing to ranges. As for
CONSUMING ranges, I think that'd be a bad idea for the same reason
basing IO entirely on ranges is a bad idea.
Interesting. Could you please give more details about this? Why is
range-based I/O a bad idea, and what can we do to make it a better one?
And what's the way that avoids writing boilerplate code but is slower?
Is that the method that calls virtual functions (or delegates) upon each
element received?
The only other use for ranges I can think of is one already mentioned by
Benji: traversal of a DOM. Ranges don't apply to SAX because that's
what pull parsing is. :D
Yah, I was thinking of the DOM traversal too. Yum.
To Andrei: I sometimes worry that your... enthusiasm for ranges is going
to leave us with range-based APIs that don't make any sense or are
horribly slow (IO in particular has me worried). But then, I suppose
that also makes you the perfect person to figure out where they CAN be used.
Plus, that way it's your fault if it doesn't work out. :P
I don't think you need to worry about my doing anything that's
inherently slow. Performance is a big concern where I'm coming from (and
also where I'm going to; incidentally all job offers I've been getting
are in high-performance computing). As for excessive enthusiasm, that's
always a risk but I'm sure I'll hear from you all if I lose my bearings.
Andrei
