Re: New jrpc.el JSONRPC library

[Aaron Ecay]

Hi João,

2018ko maiatzak 21an, João Távora-ek idatzi zuen:

> No, not "minus those keys", those keys are included in the &rest var
> too.

In that case, Stefanʼs reply tells you how to get the equivalent.

> 
> 
> Hmm:
> 
> 1. Not particularly readable for someone  that encounters the second
>    form. Can one M-. from map-and-rest into the defmacro to learn what
>    it is doing?

No, but the docstrings of all the pcase-defmacros are automatically
included in the docstring of pcase (the main entry point).  Of course,
the pcase-defmacro I wrote didnʼt have a docstring because it was just a
quick proof of concept.

> > 2. The absence of control over &allow-other-keys is a big minus. It's
>    very useful to a) check that the object isn't providing an unknown
>    key, or to check that you haven't mistyped a key name. Can you
>    code it into the pcase-defmacro?

Itʼs possible to do so, but I think it would be more perspicuous to have
the validation and destructuring separate.  One might want to assert
that the record contains some field X, without caring what Xʼs value is
(and thus, not needing to bind X to a lisp variable).

> 3. Also can you code the more complex capabilities of &key into there?
> 
>    ;; default values
>    (cl-destructuring-bind (&rest rest &key (foo "default") bar) nil
>       (list foo bar)) ;; -> ("default" nil)
> 
>    ;; provided-p
>    (cl-destructuring-bind (&rest rest &key (foo nil foo-provided-p) bar)
>           '(:bar nil :foo nil)
>       (list foo bar foo-provided-p)) ;; -> (nil nil t)
> 
>    ;; alias
>    (cl-destructuring-bind (&rest rest &key
>           ((:extremely-long-foo-with-the-airplane foo)) bar)
>           '(:extremely-long-foo-with-the-airplane 42)
>       (list foo bar)) ;; -> (42 nil)

Again one could, but I personally donʼt see the advantage of (foo nil
foo-provided-p) over (memq 'foo (map-keys my-alist)).

Anyway, I first pointed out the possibility of using pcase because I
understood you to be saying that the features of
cl-destructuring-bind+plist were not easily replicated by
anything+alists.  I hope to have shown that those features are indeed
available.  Itʼs still up to you if you are satisfied by the minutiae; I
just didnʼt want you to labor under the misconception that there are no
alternatives.  :)

> 
> I think clients of jsonrpc.el should be able to use whatever they want
> to destructure JSON (though I recommend plists and I think it should be
> the default datatype passed to the dispatcher). 

Indeed, json.el in emacs core has the json-object-type variable to
control the plist-vs-alist-ness of decoded JSON.  Maybe your library can
also work with that variable?

-- 
Aaron Ecay