[erlang-questions] SAX-like JSON Parser for Erlang

[Richard O'Keefe]

On 23/01/2013, at 8:02 PM, Bob Ippolito wrote:

> Sounds like I ought to fix up that documentation. 
> 
> 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.

That should definitely be stated in the documentation.
I don't find [foo,bar,ugh] any harder to type than <<"foo.bar.ugh">>
or for that matter "foo.bar.ugh".  Same number of characters as the
string, four fewer than the binary.  foo.bar.ugh I grant you.

There is one crucial feature of Apple's key-value coding
that does not apply in the Erlang context.  Each non-@ step
must be the name of an Objective C selector or variable.
That means that such steps cannot themselves contain dots
or at-signs.  Erlang atoms _may_ contain dots and at-signs,
and may even do so without quoting.  alpher@REDACTED is a
perfectly good Erlang unquoted atom.

> I have a key-value component for my Smalltalk library, and
> in that (1,3,4) were not issues, but (2) had my programmer's
> instincts screaming 'this is a bad idea'.  In fact one of the
> things on my TODO list is to replace
>         aPath subStrings: ' .' asClass: Symbol trimmed: true
> by
>         aPath _steps
> in order to let aPath be returned if it's a sequence of steps
> already.

Did it last night.  I decided to call it #asPropertyPath rather
than #_steps.