[cl-json-devel] proposed: improvements to decoder customization

[Boris Smilga]

On 4 Aug 2008, at 00:14, Henrik Hjelte wrote:

> I like your idea, it will make cl-json very configurable. You are on
> the spot on the requirements list in my opinion. Here are some
> thoughts:
>
> 1. There will be a lot of variables for the callback functions. Some
> may say it is ugly.
>
> But: if we can encapsule them with a function to set them all, I  
> think it is OK.

Absolutely.  I would say, something like:

(defun set-handlers (&key boolean integer float
                      start-string string-char end-string
                      start-array array-element end-array
                      start-object object-key object-element end-object)
   (setf *boolean-handler* boolean
         *integer-handler* integer
         #| the same for other handlers |# ))

> The alternative is probably to implement this OO style with what I  
> think
> they call the "strategy" pattern, but I don't think it is obviously  
> prettier
> and the performance will probably be a little bit worse.

Do you mean, along the lines of

(defclass json-parser ()
   ((boolean-handler :accessor boolean-handler :initarg :boolean
                     :type function :allocation :class)
    #| more handler slots |# ))

with specific parser semantics being subclasses of the same?

> 2. I think the A (Accumulator) version seems to be good, and If it has
> other advantages as you write, I think we should go for it.

Actually, I rather prefer B, which is cleaner, though, probably, worse
performing.  I think I'm going to implement both and run some heavy
workload tests to see how bad the regression could be, and then we'll
decide.

> 3. Will you do it, or should we just put it on the TODO list until
> someone wants to do it?

I'll do it.  It's not that much work.  For the time being, let's keep
things in a separate file (or even two of them, for the two options of
devolving information).  We'll then copy over the better one into
decoder.lisp and discard the other one.

> By the way, some things that I might want to do if we should release a
> new version:
> * remove the parenscript dependency.

The only feature of parenscript used by cl-json is the function
SYMBOL-TO-JS.  I can, of course, substitute my own implementation.

> * add a little sample implementation of JSONP

This, in my best judgement, is not the most urgent priority, and can
be easily added after improving the encoder (e.g. in the way that Hans
argues for).

Sincerely,
  - B.Sm.