From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Newsgroups: gmane.emacs.bugs Subject: bug#21798: 25.0.50; [PATCH] Add support for retrieving paths to JSON elements Date: Fri, 06 Nov 2015 17:31:28 +0100 Message-ID: <1446827488.11140.2@smtp.gmail.com> References: <1446281162.2607.0@smtp.gmail.com> <5634CEE7.3070200@yandex.ru> <1446407553.4906.0@smtp.gmail.com> <1446420466.13180.0@smtp.gmail.com> <56381558.7050607@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=-CsgJEp8htxb4vhJxa7sF" X-Trace: ger.gmane.org 1446827544 5943 80.91.229.3 (6 Nov 2015 16:32:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 16:32:24 +0000 (UTC) Cc: 21798@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 06 17:32:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zujvu-0001SD-Qg for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Nov 2015 17:32:11 +0100 Original-Received: from localhost ([::1]:39821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zujvu-00044x-8z for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Nov 2015 11:32:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zujvp-00044o-MB for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2015 11:32:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zujvm-0007VM-VP for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2015 11:32:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zujvm-0007VF-Rc for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2015 11:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zujvm-0000xl-P2 for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2015 11:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Nov 2015 16:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21798 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 21798-submit@debbugs.gnu.org id=B21798.14468275143676 (code B ref 21798); Fri, 06 Nov 2015 16:32:02 +0000 Original-Received: (at 21798) by debbugs.gnu.org; 6 Nov 2015 16:31:54 +0000 Original-Received: from localhost ([127.0.0.1]:56022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zujvd-0000xD-O0 for submit@debbugs.gnu.org; Fri, 06 Nov 2015 11:31:54 -0500 Original-Received: from mail-wi0-f173.google.com ([209.85.212.173]:36562) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZujvH-0000wR-6j for 21798@debbugs.gnu.org; Fri, 06 Nov 2015 11:31:52 -0500 Original-Received: by wimw2 with SMTP id w2so33722612wim.1 for <21798@debbugs.gnu.org>; Fri, 06 Nov 2015 08:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version:content-type; bh=tTVgq13mGrTqX0MaRghSCJ84+BGhWakK92h0EY4yxL0=; b=u1Nl5Ky/ZkUULyDnkaUS0ccTfBgI5OKlxQlXC/mqS6s/caLfmOiH946U2/Jyf+jSg8 Ehg5XGH5VtPrWZZHRVhhragopAQN6FR7az2gBAP7bBCZP6R3RmaA2Pqm/rmnlTBri+fJ /boZOwsJVKpwXsz9otcoWxmLDRviFPO/FTSYujpBlcMAyilCBDoJDR7S6ifATZlAUJ6B G35nDRmnHC47wbfYv0xJgkLFfd3sUgdFGA5dgabVp7MLhRt8s3xza9+PZrypXpGjTB0v yC9e54FMPiMJ3hHzT74SE8lRRTyp7M9BolNxs53KE9uqHh4RtRbf6pQJrXN6gKrjj+n/ YlHw== X-Received: by 10.195.18.67 with SMTP id gk3mr15206433wjd.35.1446827490515; Fri, 06 Nov 2015 08:31:30 -0800 (PST) Original-Received: from [192.168.101.25] ([77.40.215.202]) by smtp.gmail.com with ESMTPSA id 186sm3796700wmp.10.2015.11.06.08.31.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Nov 2015 08:31:29 -0800 (PST) In-Reply-To: <56381558.7050607@yandex.ru> X-Mailer: geary/0.10.0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108500 Archived-At: --=-CsgJEp8htxb4vhJxa7sF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Dmitry, thanks for the feedback. On Tue, Nov 3, 2015 at 3:00 AM, Dmitry Gutov wrote: > I have to say, I'm still not very comfortable with mixing it sort of=20 > alien logic inside json-read-object and json-read-array (would anyone=20 > else like to chime in with their opinion?). I understand your uneasiness, I feel the same way after you pointed it out. > Here's an idea: both json-read-object-1 and json-read-array-2 will=20 > advise json-read to add the new logic around calls to it (there will=20 > have to be some guard in the advice, so that recursive calls are run=20 > unmodified). I'm reluctant to use advises for it, not based on my own experience, but based on advice from the Elisp manual: > [...] advice should be reserved for the cases where you cannot modify > a function=E2=80=99s behavior in any other way. [...] In particular,=20 > Emacs=E2=80=99s > own source files should not put advice on functions in Emacs. (There > are currently a few exceptions to this convention, but we aim to > correct them.) Here we do have a chance to modify the functions' behavior. How about a sort of compromise between our approaches: provide 'json-read-object' and 'json-read-array' with pre- and post-read callback functions, that are only called when they're set. That would make it possible to leverage the power of 'json-read-object' and 'json-read-array' by binding the callback functions, without mixing alien logic into them. That would also make it a lot cleaner when adding other extensions to them in the future, compared to my original suggestion. If that sounds good to you, I'll cook up a new patch! -- Simen = --=-CsgJEp8htxb4vhJxa7sF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Dmitry, thanks for the feedback.

On Tue, Nov 3, 2015 at 3:00 A= M, Dmitry Gutov <dgutov@yandex.ru> wrote:
I have to say, = I'm still not very comfortable with mixing it sort of alien logic inside js= on-read-object and json-read-array (would anyone else like to chime in with= their opinion?).

I understand your uneasi= ness, I feel the same way after you pointed it
out.

Her= e's an idea: both json-read-object-1 and json-read-array-2 will advise json= -read to add the new logic around calls to it (there will have to be some g= uard in the advice, so that recursive calls are run unmodified).

I'm reluctant to use advises for it, not based on my= own experience, but
based on advice from the Elisp manual:
=

[...] advice should be reserv= ed for the cases where you cannot modify
a function=E2=80=99s beh= avior in any other way. [...] In particular, Emacs=E2=80=99s
own = source files should not put advice on functions in Emacs. (There
= are currently a few exceptions to this convention, but we aim to
= correct them.)

Here we do have a chan= ce to modify the functions' behavior.

How about a = sort of compromise between our approaches: provide
'json-read-obj= ect' and 'json-read-array' with pre- and post-read
callback funct= ions, that are only called when they're set. That would
make it p= ossible to leverage the power of 'json-read-object' and
'json-rea= d-array' by binding the callback functions, without mixing
alien = logic into them.

That would also make it a lot cle= aner when adding other extensions to
them in the future, compared= to my original suggestion.

If that sounds good to= you, I'll cook up a new patch!

-- Simen
= --=-CsgJEp8htxb4vhJxa7sF--