> [1]
>
> type ListSpecificHostedServicesRequest struct {
> - ServiceNames []string
> + ServiceNames []string
> + ServiceNamePrefix string
> }
>
> This is kind of ugly. It's muddying the expected behaviour of
> ListSpecificHostedServices. I think it also falls into the realms of
> Jeroen's Swiss Army Knife antipattern.
>
> How about allowing ServiceNames to contain globs? I don't think that
> services can have glob pattern characters in them, so it should be
> safe (and they can be escaped if necessary anyway).
>
> See http://golang.org/pkg/path/#Match
>
> Alternatively, you could split the prefix matching functionality out
> into a separate ListHostedServicesWithPrefix function.
I must say I started with a separate method but then I found that the new functionality was fitting nicely into the existing method. Can you elaborate a bit on what exactly is ugly here? The two constrains do not really step on each other's toes.
> [1] tedServicesRequ est struct { tedServices. I think it also falls into the realms of golang. org/pkg/ path/#Match cesWithPrefix function.
>
> type ListSpecificHos
> - ServiceNames []string
> + ServiceNames []string
> + ServiceNamePrefix string
> }
>
> This is kind of ugly. It's muddying the expected behaviour of
> ListSpecificHos
> Jeroen's Swiss Army Knife antipattern.
>
> How about allowing ServiceNames to contain globs? I don't think that
> services can have glob pattern characters in them, so it should be
> safe (and they can be escaped if necessary anyway).
>
> See http://
>
> Alternatively, you could split the prefix matching functionality out
> into a separate ListHostedServi
I must say I started with a separate method but then I found that the new functionality was fitting nicely into the existing method. Can you elaborate a bit on what exactly is ugly here? The two constrains do not really step on each other's toes.