From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dINZz-000245-OL for guix-patches@gnu.org; Tue, 06 Jun 2017 19:08:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dINZy-00009C-Qz for guix-patches@gnu.org; Tue, 06 Jun 2017 19:08:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:57334) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dINZy-000097-N9 for guix-patches@gnu.org; Tue, 06 Jun 2017 19:08:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dINZy-00039Y-HM for guix-patches@gnu.org; Tue, 06 Jun 2017 19:08:02 -0400 Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87mv9m7g0t.fsf@elephly.net> Date: Wed, 07 Jun 2017 01:07:41 +0200 In-Reply-To: <87mv9m7g0t.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 05 Jun 2017 14:52:50 +0200") Message-ID: <87bmq07m0y.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ricardo Wurmus Cc: 27155@debbugs.gnu.org Hi Ricardo, Ricardo Wurmus skribis: > I think it is useful to have the ability to add rewriters at the end of > service composition. In my opinion it is always good to have an escape > hatch, and this seems to fit the bill. But I agree that it is not > an elegant solution, and I wouldn=E2=80=99t want to advocate using it. Right. As discussed on IRC, one problem is ordering: if there are several users of this features for a given service, you can=E2=80=99t really tell what=E2=80=99s going to happen, unless the modifications happen to be commutable. > As to your second idea: it seems tedious for service writers to have to > anticipate the ways in which services could be extended (here given by > providing extension points). Boilerplate aside, I=E2=80=99m not sure it would be this tedious. > Would it make more sense to allow *extensions* to specify how they > should be applied rather than letting services define extension points? > This would shift the burden away from services to service extensions. > Extensions would still need to provide a way of extending the parent > service, but this could be optional. What would it look like? It seems to me there are two options: either service type specify how they can be extended, or they expose their raw values letting any extension alter it (the patch I sent). Thanks for your feedback! Ludo=E2=80=99.