[erlang-questions] SAX-like JSON Parser for Erlang
Thu Jan 24 01:06:37 CET 2013
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. 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
> aPath _steps
> in order to let aPath be returned if it's a sequence of steps
Did it last night. I decided to call it #asPropertyPath rather
More information about the erlang-questions