From: joaotavora@gmail.com (João Távora)
To: Aaron Ecay <aaronecay@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: New jrpc.el JSONRPC library
Date: Wed, 23 May 2018 21:40:35 +0100 [thread overview]
Message-ID: <871se2ds1o.fsf@gmail.com> (raw)
In-Reply-To: <87r2m26yrg.fsf@gmail.com> (Aaron Ecay's message of "Wed, 23 May 2018 18:57:23 +0100")
Aaron Ecay <aaronecay@gmail.com> 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
next prev parent reply other threads:[~2018-05-23 20:40 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-10 22:34 [ELPA] New package: eglot João Távora
2018-05-11 6:19 ` Eli Zaretskii
2018-05-11 11:29 ` João Távora
2018-05-11 12:15 ` Eli Zaretskii
2018-05-18 16:27 ` New jrpc.el JSONRPC library (Was: [ELPA] New package: eglot) João Távora
2018-05-19 8:46 ` Eli Zaretskii
2018-05-20 15:54 ` New jrpc.el JSONRPC library João Távora
2018-05-20 16:02 ` Eli Zaretskii
2018-05-29 1:08 ` João Távora
2018-06-28 12:13 ` [PATCH] jsonrpc.el João Távora
2018-06-28 13:18 ` Eli Zaretskii
2018-06-28 13:23 ` João Távora
2018-06-28 13:40 ` Eli Zaretskii
2018-05-20 19:13 ` New jrpc.el JSONRPC library Clément Pit-Claudel
2018-05-20 20:35 ` Josh Elsasser
2018-05-20 23:22 ` João Távora
2018-05-21 3:32 ` Josh Elsasser
2018-05-20 23:11 ` João Távora
2018-05-21 0:14 ` Clément Pit-Claudel
2018-05-19 11:34 ` New jrpc.el JSONRPC library (Was: [ELPA] New package: eglot) Philipp Stephani
2018-05-19 14:11 ` Eli Zaretskii
2018-05-20 15:43 ` New jrpc.el JSONRPC library João Távora
2018-05-20 16:06 ` Eli Zaretskii
2018-05-20 16:18 ` João Távora
2018-05-21 13:30 ` Aaron Ecay
2018-05-21 13:43 ` João Távora
2018-05-21 14:37 ` Aaron Ecay
2018-05-21 19:06 ` João Távora
2018-05-23 17:57 ` Aaron Ecay
2018-05-23 18:02 ` Stefan Monnier
2018-05-23 20:40 ` João Távora [this message]
2018-05-24 2:07 ` Stefan Monnier
2018-05-21 14:42 ` Stefan Monnier
2018-05-24 10:02 ` Philipp Stephani
2018-05-24 17:25 ` João Távora
2018-05-12 15:47 ` [ELPA] New package: eglot Stefan Monnier
2018-05-14 10:55 ` Bozhidar Batsov
2018-05-14 14:14 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871se2ds1o.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=aaronecay@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.