<div dir="ltr">Sounds like I ought to fix up that documentation. <div><br></div><div>My primary goal was to just clone Apple's Key-Value Coding API (which I should've stated more explicitly in the README). I never used this library for anything but introspecting data structures interactively in the shell. In that environment I find it to be friendlier if I can input the paths as an atom or string. Efficiency wasn't much of a concern.</div>
<div><br></div><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 22, 2013 at 9:29 PM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 23/01/2013, at 4:41 PM, Bob Ippolito wrote:<br>
<br>
> JSON pointers are much less powerful than XPath, it's not really a query language. No predicates, result must be a single node. It's just '/foo/bar/baz/0' instead of 'obj.foo.bar.baz[0]' (in JS).<br>

><br>
> Something in-between (more powerful than JSON pointers, less powerful than XPath) would be something like <a href="https://github.com/etrepum/kvc" target="_blank">https://github.com/etrepum/kvc</a> -- It won't generate results from a stream, so you'd need to use it with a standard JSON parser.<br>

<br>
</div>The examples in the README.md of <a href="https://github.com/etrepum/kvc" target="_blank">https://github.com/etrepum/kvc</a><br>
do things like<br>
<br>
wibble =:= kvc:path(foo.bar.baz, [{foo, [{bar, [{baz, wibble}]}]}]).<br>
<br>
This feels wrong to me.  A path should be a _list_ of<br>
step descriptions, [foo,bar,bar].  Reasons:<br>
(1) You can have integer steps (this element of a tuple)<br>
    as well as atom steps (this entry in a dict &c).<br>
    And you can also have atom steps that _look_ like integers.<br>
(2) It is more efficient not to have to split a path into steps<br>
    at run time.<br>
(3) Perhaps the most painfully obvious:<br>
    a named step might need to include a dot (or any other fixed<br>
    character) in its name.<br>
(4) Given a recursive data structure with a small set of labels,<br>
    using dotted atoms you can quickly exhaust the size of<br>
    Erlang's atom table.<br>
<br>
In many ways, this is a perfect example of "strings are wrong".<br>
The abstract concept we need here is<br>
   "path"<br>
and<br>
   "path" = sequence of "step"<br>
and<br>
   "step" = receiver-specific position or label<br>
<br>
Packing a path up as a dotted atom or any other kind of<br>
string representation means having to recover at run time<br>
and unreliably information that has been _hidden_ inside<br>
the string, when it could have been made directly available<br>
as a simple data structure.<br>
<br>
I have a key-value component for my Smalltalk library, and<br>
in that (1,3,4) were not issues, but (2) had my programmer's<br>
instincts screaming 'this is a bad idea'.  In fact one of the<br>
things on my TODO list is to replace<br>
        aPath subStrings: ' .' asClass: Symbol trimmed: true<br>
by<br>
        aPath _steps<br>
in order to let aPath be returned if it's a sequence of steps<br>
already.<br>
<br>
Fortunately(?) the README.md is incomplete, and that KVC<br>
implementation _does_ accept a list of steps (which look as<br>
though they have to be binaries).  That module is better than<br>
it sounds.<br>
<br>
By the way, things like this remind me irresistibly of<br>
Nicklaus Wirth's "Professor Cleverbyte's Visit to Heaven"<br>
(Software Practice and Experience, Vol 7 pp155-158, 1977).<br>
<br>
<br>
</blockquote></div><br></div></div></div></div></div>