Re: New jrpc.el JSONRPC library

[João Távora]

Aaron Ecay <address@hidden> writes:

> Itʼs possible to do so, but I think it would be more perspicuous to have
> the validation and destructuring separate.

So that if you change one you have to change the other? And type the
key over and over?

> 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).

Just use '_'

   (cl-destructuring-bind (&key _boring-key very-important)
       '(:very-important 42 :boring-key 92)
       very-important)
  
> Again one could, but I personally donʼt see the advantage of (foo nil
> foo-provided-p) over (memq 'foo (map-keys my-alist)).

You're comparing apples to oranges. Here's the comparison: with this
form, where "foo" appears once.

   (cl-destructuring-bind (&rest all &key (foo 'default provided-p))
      a-plist-map
   ...)

You are, to the best of my pcase.el knowledge so far, doing the same as:

   (pcase-let* ((`(. ,(and all (map foo))) any-kind-of-map)
                (provided-p (and (memq 'foo (map-keys all)) t))
                (foo (if provided-p foo 'default)))
     (some (code (to-check (for-invalid-keys-in) all) '(foo)))
     ...
     )

Where foo appears 5 times.

And I didn't even mention the fact that you can use the cl-dbind lambda
list in a cl-defmethod, for example.  If you `apply' it to a JSON object
you get all the args ready to use + the error reporting when you botch
the funcall because you botched the object (or the spec).

You could do similar stuff with pcase-lambda (though, again, much more
verbosely). But then again that isn't as versatile and pervasive as
cl-defgeneric.

> 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.

Sorry, but they aren't: you have to program them (which is what I
asked you to demonstrate).

... just like cl-dbind doesn't have the main feature of map.el, which is
a uniform interface to different map types. But we were discussing
specifically the merits of plists.

> Itʼs still up to you if you are satisfied by the minutiae;

You know what they say: "the devil is in the minutiae!" :-)

> 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?

Yes, maybe. It must work with json.c above all (and it doesn't support
plists apparently).

João