[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27155] [PATCH 0/2] Support service extensions on the "final" servic
[bug#27155] [PATCH 0/2] Support service extensions on the "final" service values
Fri, 16 Jun 2017 01:12:15 +0800
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
address@hidden (Ludovic Courtès) writes:
> Hi Ricardo,
> Ricardo Wurmus <address@hidden> 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’t 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’t really
> tell what’s going to happen, unless the modifications happen to be
>> 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’m 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?
Maybe allow a service to override extensions specified by its
It can be:
(default-extensions (list ...))
(extension-points (list ...))))
So we can change what service actually do, this is really powerful!