Pretty high latency, I know, but this didn't became a problem until now (again):
About a year ago I rewrote the Parser.XML.Tree to be much more object oriented. The major design goal was to be able to easily redefine the produced nodes in the tree. Basically you could do
class Node { inherit Parser.XML.Tree.Node;
void my_method() { return 7; } }
Node n = Node(Stdio.read_file("file.xml"));
and get my_method() in all the produced nodes.
Today we are however back to the one-class-per-node-type-approach where you basically has to inherit the entire Parser.XML.Tree module to be able to modify its behaviour. Why is that?
Mainly because having one class per node type is a more object- oriented approach, and it also leads to much improved type-checking and optimizer possibilities.
On Mon, Mar 19, 2007 at 09:15:00AM +0000, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
Mainly because having one class per node type is a more object- oriented approach,
how does having more classes make something more object oriented?
what a class or an object is should really be defined by your needs, and not by its object orientedness.
and it also leads to much improved type-checking and optimizer possibilities.
could you elaborate on that? when reading xml i am mostly interested in the data thats inside it and the node structure maybe. both should be easy to manipulate and rewrite to xml. i don't see what i'd gain from type checking here (unless you add a dtd that tells you what nodes are supposed to go where)
most often i want to handle multiple nodes with the same code. having different classes for each most likely complicates that. not that i have tried, as i found the simple parser which just turns the xml tree into a nested array (which is exactly what xml is: a structured list of data)
xml does not have types, and unless there is extra information (like from a dtd) the parser can't possibly know wether two nodes which look the same should actually be the same type or not.
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Martin Bähr -
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum