On 02/06/2010 7:24 PM, James Paige wrote:
On Wed, Jun 02, 2010 at 07:14:54PM -0400, Mike Caron wrote:
On 02/06/2010 7:09 PM, James Paige wrote:
On Wed, Jun 02, 2010 at 07:03:37PM -0400, Mike Caron wrote:
On 02/06/2010 7:02 PM, James Paige wrote:
On Wed, Jun 02, 2010 at 06:44:30PM -0400, Mike Caron wrote:
On 02/06/2010 5:52 PM, James Paige wrote:
Is this an accurate description of what Rpath is supposed to do?
node = Reload.RPath(doc, "/party/slot[3]/stats/stat[0]/max")
Which would look in the root node for a node named "party",
then look in the party node for a node named "slot" with int value 3,
then look in the slot node for a node named stats,
then look in the stats node for a node named "stat" with int value 0,
then look in the stat node for a node named "max" and return it
If that is indeed what RPath is supposed to do, I feel up to the task of
implementing it.
And if that is NOT what RPath is supposed to mean, then I still feel up
to implementing it, but I will call it something different :)
Almost. RPath is intended to mimic XPath, which would interpret your
example as:
Match the root node named "party", then
Match the third sub-node named "slot", then
Match the first node named "stats", then
Throw an error, because indicies are one-based, but if it was a one,
Match the first node named "stat", then
Match the first node named "max"
Return this node
To do what you suggest, the expression would look like:
party/slot[.="3"]/stats/stat[.="0"]/max
And match it against the document root, whatever it may be. Explanation:
1. A leading slash matches the *document*, not the root node. (Actually,
in XML, there's a hidden node above the first tag. The leading slash
matches that)
2. The dot represents the "current" node
3. The expressions inside the brackets are like WHERE clauses in SQL
4. A number by itself means the Xth node.
You can do stuff like
no...@foo="bar"]
Which matches "node" who has an attribute "foo" whose value is "bar",
and is the intended way to match nodes (Incidentally, this is why I
reserved the leading @ for attributes converted from XML).
So, where does this leave RPath (which I have not been describing so
far)? I suggest we stick closer to XPath, but perhaps with some
limitations:
1. XPath allows a bunch of pseudo functions inside the brackets, things like
node[next(.) == "foo"]
Which would match "node", whose next sibling's value equalled "foo". We
don't need that.
2. Allow matching based on children alone, so we don't need . to mean
the current node.
3. Recommend that people don't use the content of the node itself to
distinguish between similar nodes. Use children for that. (Or, better,
give the nodes distinct names)
If you need clarification, let me know (or pull me into IRC or something)
Okay. Sounds like RPath is a lot heavier than what I have in mind
I will continue with my simplified implementation, but I will call it
something else to avoid confusion.
Probably Reload.Ext.NodeByPath
Maybe, but really, my entire email could probably have been distilled
into the following sentence:
"Correct, except I would recommend that [3] means the third node, not a
node whose value is 3".
The reason I don't want to do that is because of sparse arrays.
For example, when I write the globals into the rsav file, I only write
the non-zero values.
Each "global" node has a value which is the global id number, and a
child node named "int" which has its integer value.
So I want "/script/globals/global[47]/int" to give me the node
containing the value for global ID 47, not the 47th global saved in the
file.
Well, I guess I can agree with that, but perhaps a better way would be
to store them like:
<globals>
<global1>123</global1>
<global43>1</global43>
</globals>
Or, even,
<globals>
<global>
<num>1</num>
<val>123</val>
</global>
<global>
<num>43</num>
<val>1</val>
</global>
</globals>
I'm partial to the first one, especially since another idea I had on the
drawing-board (in my brain, not on the wiki page) was to have each node
maintain a hash with all its children. Then, finding global2345 would be
really fast, much faster than iterating each child and looking for one
whose value is 2345.
faster is good :)
I can see how that would improve seek time. What impact would that hash
have on memory usage and loading time?
Loading time, would be increased, but by a negligible amount (like, it
would have a measurable effect on the massive files we were playing with
the other day.)
I was experimenting with:
<globals>
<1>123</1>
<43>1</43>
</globals>
but TMC talked me out of it :)
Wait, what's wrong with that? That's my alternate suggestion #1!
(except, mine involves more string concatenation!)
Perhaps it needs further debate.
I would like to hear TMC's opinion on this.
---
James
--
Mike
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
