[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New jrpc.el JSONRPC library

From: João Távora
Subject: Re: New jrpc.el JSONRPC library
Date: Wed, 23 May 2018 21:40:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]