Stefan Behnel added the comment:

Eli, seeing our discussion so far, ISTM that the parser-target interface is at 
the very heart of our disagreement.

For me, it's a good design that provides a clean separation of concerns between 
the parser that generates events, and the target (usually, but not necessarily 
a TreeBuilder) that processes them. The link back is then provided by the 
close() method (provided by both, BTW), which terminates the parsing process 
and passes the result through to the user. That result may be a tree, but 
that's completely up to the target, and whatever comes back is transparent to 
the parser (there's an example of that in the docs, BTW). That's a clean 
separation of concerns that I would like to copy in the design of the 
XMLPullParser (in fact, by inheriting from XMLParser). Extrapolating this exact 
design, whatever comes back from the callback methods should be transparent to 
the parser and should control the objects that the XMLPullParser collects for 
its events. I.e., it's the target's sole responsibility to convert the parser's 
calls into objects that make up both the collected events and the result ret
 urned by the parser's close() methods. Again, I consider this a very clean 
separation of concerns.

Essentially, I embrace the fact that the user is standing on both sides of the 
API and can control both the generation of the event objects (by providing a 
target object) and the processing of the events in front of the parser. To me, 
this is a very clean and extremely flexible design, and I hope it's clearer now 
why I consider it an excellent feature.

Now, several of your comments so far indicate an aversion towards the 
parser-target interface because it allows arbitrary objects to be returned by 
uncontrollable, user provided code, thus "tainting" the otherwise clean tree 
building interface of the new pull parser. On the other hand, you also stated 
that you would like to keep a separation between the parser and the TreeBuilder 
and do not want the parser to know about trees, so I guess that means that you 
also wouldn't want the parser to enforce any kind of tree building constraints 
on whatever the result of the parsing process is. As I said before, it's 
utterly unclear to me how both of these go together, but that's what I could 
extract from the discussion so far.

Would it be possible for you to clarify your own opinion on this topic, and, 
specifically, how you envision the role of the parser, the target and their 
separation of concerns during the event generation? I think this would help us 
get this discussion a little forward.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to