[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)
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
- Re: New jrpc.el JSONRPC library (Was: [ELPA] New package: eglot), (continued)
- Re: New jrpc.el JSONRPC library, Aaron Ecay, 2018/05/21
- Re: New jrpc.el JSONRPC library, João Távora, 2018/05/21
- Re: New jrpc.el JSONRPC library, Aaron Ecay, 2018/05/21
- Re: New jrpc.el JSONRPC library, João Távora, 2018/05/21
- Re: New jrpc.el JSONRPC library, Aaron Ecay, 2018/05/23
- Re: New jrpc.el JSONRPC library, Stefan Monnier, 2018/05/23
- Re: New jrpc.el JSONRPC library,
João Távora <=
- Re: New jrpc.el JSONRPC library, Stefan Monnier, 2018/05/23
- Re: New jrpc.el JSONRPC library, Stefan Monnier, 2018/05/21
- Re: New jrpc.el JSONRPC library, Philipp Stephani, 2018/05/24
- Re: New jrpc.el JSONRPC library, João Távora, 2018/05/24
Re: [ELPA] New package: eglot, Stefan Monnier, 2018/05/12