From: Catonano <catonano@gmail.com>
To: Jelle Licht <jlicht@fsfe.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Maintaining implementations of similar utility functions like json-fetch
Date: Thu, 1 Feb 2018 12:54:15 +0100 [thread overview]
Message-ID: <CAJ98PDxgc9G4dQ=m9XQ_yq+OXYdxx51qnesLxa_O7RCfT_7B=w@mail.gmail.com> (raw)
In-Reply-To: <CAPsKtfKdPpxW+ctdHtUBfE-MWpjKQzU39M9j2FqD_bwybYxDXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
2018-01-31 18:32 GMT+01:00 Jelle Licht <jlicht@fsfe.org>:
> Hi Ludo',
>
>
> 2018-01-27 17:09 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:
>
>> Hello!
>>
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>> > I noticed that there are currently two very similar functions for
>> fetching
>> > json data; `json-fetch' in (guix import json) and `json-fetch*' in (guix
>> > import github).
>> >
>> > Some things I noticed:
>> > - Dealing with http error codes seems to be a bit more robust in
>> > `json-fetch*'.
>> > - Making sure that (compliant) servers give responses in the proper
>> format
>> > seems more robust in `json-fetch' due to using Accept headers.
>> > - Dealing with the fact that json responses are technically allowed to
>> be
>> > lists of objects, which `json-fetch' does not handle gracefully.
>> >
>> > For this issue specifically, would it make sense to combine the two
>> > definitions into a more general one?
>>
>> Definitely, we should just keep one. It’s not even clear how we ended
>> up with the second one.
>>
>
> I even had a third one in my local tree which happened to have a conflict,
> which
> is how I found out in the first place, so I understand how these things
> can happen.
>
>>
>> > My more general concern would be on how we can prevent bug fixes only
>> being
>> > applied to one of several nearly identical functions. IOW, should we
>> try to
>> > prevent situations like this from arising, or is it okay if we somehow
>> make
>> > sure that fixes should be applied to both locations?
>>
>> We should prevent such situations from arising, and I think we do.
>>
>> The difficulty is that avoiding duplication requires knowing the whole
>> code base well enough. Sometimes you just don’t know that a utility
>> function is available so you end up writing your own, and maybe the
>> reviewers don’t notice either and it goes through; or sometimes you need
>> a slightly different version so you duplicate the function instead of
>> generalizing it.
>>
>> Anyway, when we find occurrences of this pattern, we should fix them!
>>
>
> I basically added the robust features of `json-fetch*' to the exported
> `json-fetch'
> instead, and all existing functionality seems to work out as far as I can
> see.
>
> I did notice that I now produce hash-tables by default, and some of the
> existing usages of `json-fetch*' expect an alist instead. What would be a
> guile-
> appropriate way of dealing with this? I currently have multiple
> `(hash-table->alist (json-fetch <...>))' littered in my patch which seems
> suboptimal,
> but always converting the parsed json into an alist seems like it might
> also not be
> what we want.
>
of course I' d wait for a thought by some more competent guiler, but I' d
like to offer my take on this
The new function could take one further argument, a boolean
If the boolean is true, it could return a hash table
Otherwise, it could return a list
If the majority of call sites expect a list, the further argument could set
to false as default
So you' d only have to fix those call sites that want a hash table instead
If, instead, the majority of call sites want a hash table, your procedure
would return a hash table by default and a list by a further argument, so
you' d have to fix a minority of call sites anyway
I hope I didn' t make myself a fool :-/
> Thanks,
> Ludo’.
>
> - Jelle
>
[-- Attachment #2: Type: text/html, Size: 5132 bytes --]
next prev parent reply other threads:[~2018-02-01 11:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 15:28 Maintaining implementations of similar utility functions like json-fetch Jelle Licht
2018-01-27 16:09 ` Ludovic Courtès
2018-01-31 17:32 ` Jelle Licht
2018-02-01 11:54 ` Catonano [this message]
2018-02-01 12:14 ` Gábor Boskovits
2018-02-05 13:12 ` Ludovic Courtès
2018-02-05 14:51 ` Alex Vong
2018-06-10 18:50 ` Jelle Licht
2018-06-10 19:54 ` Ludovic Courtès
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ98PDxgc9G4dQ=m9XQ_yq+OXYdxx51qnesLxa_O7RCfT_7B=w@mail.gmail.com' \
--to=catonano@gmail.com \
--cc=guix-devel@gnu.org \
--cc=jlicht@fsfe.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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).