[bug#27155] [PATCH 0/2] Support service extensions on the "final" service values

[宋文武]

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
> 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’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
type?

It can be:
--8<---------------cut here---------------start------------->8---
(define etc-service-type
  (service-type
    (name 'etc)
    (default-extensions (list ...))
    (extension-points (list ...))))

(define builtin-etc-service
  (... %base-services))

(define my-etc-service
  (service etc-service-type
    (service-value builtin-etc-service)
    #:extensions
    (list (service-extension
            activation-service-type
            activate-my-etc-files-in-my-way)
          ...)))
--8<---------------cut here---------------end--------------->8---

So we can change what service actually do, this is really powerful!