Is it acceptable to make the optional parameter as varargs

[Amarjeet Anand]

Is it acceptable to make the optional parameter as varargs?
I wrote code in my package like ...

package backoff

func New(options ...Options) *backOff {
   backOff := defaultBackOff()
   if len(options) == 0 {
      return backOff
   }

   // override default values
   if len(options) > 1 {
      panic("only 1 backOffOption allowed")
   }
   optn := options[0]
   backOff.options = &optn

   if optn.Delay_ms > 0 {
      backOff.delay_ms = optn.Delay_ms
   }
   return backOff
}

So that in other package, it can be used as backoff.New() when option is not needed(which will be the case most of the time).

Is using varargs for optional parameter is ok? Or am I abusing the Variadic Functions feature?

[James]

This reminds me of functional options which I think are used quite widely for this purpose.

See https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis and https://github.com/tmrts/go-patterns/blob/master/idiom/functional-options.md

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com.

[Amarjeet Anand]

Thanks James for your response and the amazing posts.

[robert engels]

I think the Builder pattern is easier than this, and it retains the property of both ‘config struct’ and ‘multiple args’ versions that the implementation can re-order and validate option in aggregate easier - but most of all is doesn’t pollute that package with top-level public functions. The builder pattern uses instance methods to tie the function to the configuration structure,

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com.

[Amarjeet Anand]

Thanks Robert for the nice idea.

Using builder pattern to set options didn't come to my mind. Looks really clean.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com.

[ser...@netdata.cloud]

Hello Amarjeet,

You can actually don't check if len(options) is greater than one – if your package provides only single implementation of Option, than there is no way to pass something different than that backoffOption. But it also brings an ability to extend your constructor later. There is a great article about optional arguments: https://sagikazarmark.hu/blog/functional-options-on-steroids/

I'd rather prefer optional arguments to builder.

--

Regards,

Sergey.

[Robert Engels]

You can use builder to build options or the server. It is a much cleaner and self documenting method. 

On May 25, 2020, at 12:51 PM, ser...@netdata.cloud wrote:



--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1e07b530-7805-4221-a6a0-61de6ca219cb%40googlegroups.com.

[boj...@gmail.com]

I actually published a whole article listing the various patterns for optional parameters, just a few hours ago: https://bojanz.github.io/optional-parameters-go/

Your code looks fine to me, it is a reasonable tradeoff.

[roger peppe]

I'm not familiar with the Builder pattern. Could you provide a good example of its use in a Go package?

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com.

[robert engels]

NatsIO which is a pretty major application has this https://www.javadoc.io/doc/io.nats/jnats/2.0.0/io/nats/client/Options.Builder.html

This is a pretty good “tutorial” - and I think you can see how it can be applied to parameters or instance creation (e.g. the server instance). see https://vaskoz.wordpress.com/2014/04/07/golang-builder-pattern/