[go-nuts] 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?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[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

On Mon, 25 May 2020 at 14:57, Amarjeet Anand 
wrote:

> 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?
>
>
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAFuMYUwW2DCw4Ks9Ho94LKtwLDpf%2B7YMkrMT1hNss5murmcsHw%40mail.gmail.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[Amarjeet Anand]

Thanks James for your response and the amazing posts.

On Mon, May 25, 2020 at 9:01 AM James  wrote:

> 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
>
> On Mon, 25 May 2020 at 14:57, Amarjeet Anand 
> wrote:
>
>> 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?
>>
>>
>>
>>
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[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,

> On May 24, 2020, at 11:36 PM, Amarjeet Anand  
> wrote:
> 
> Thanks James for your response and the amazing posts.
> 
> On Mon, May 25, 2020 at 9:01 AM James  > wrote:
> 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 
> 
> On Mon, 25 May 2020 at 14:57, Amarjeet Anand  > wrote:
> 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?
> 
> 
> 
> 
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
>  
> .
> 
> -- 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com
>  
> .

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[Amarjeet Anand]

Thanks Robert for the nice idea.
Using builder pattern to set options didn't come to my mind. Looks really
clean.

On Mon, 25 May, 2020, 10:55 AM robert engels,  wrote:

> 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,
>
> On May 24, 2020, at 11:36 PM, Amarjeet Anand 
> wrote:
>
> Thanks James for your response and the amazing posts.
>
> On Mon, May 25, 2020 at 9:01 AM James  wrote:
>
>> 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
>>
>> On Mon, 25 May 2020 at 14:57, Amarjeet Anand <
>> amarjeetanandsi...@gmail.com> wrote:
>>
>>> 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?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
>>> 
>>> .
>>>
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com
> 
> .
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAORUUQVVMu7XgKMkouq2dRCjQjnLbT5qx9Q7zKnG7tTj35Uz_w%40mail.gmail.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[roger peppe]

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

On Mon, 25 May 2020, 06:25 robert engels,  wrote:

> 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,
>
> On May 24, 2020, at 11:36 PM, Amarjeet Anand 
> wrote:
>
> Thanks James for your response and the amazing posts.
>
> On Mon, May 25, 2020 at 9:01 AM James  wrote:
>
>> 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
>>
>> On Mon, 25 May 2020 at 14:57, Amarjeet Anand <
>> amarjeetanandsi...@gmail.com> wrote:
>>
>>> 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?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
>>> 
>>> .
>>>
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com
> 
> .
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgacgG4bmnMybBhB5OzgTLLsQGRccRGevOTfac%2BqCTUU9wKA%40mail.gmail.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[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/

> On May 29, 2020, at 5:02 PM, roger peppe  wrote:
> 
> I'm not familiar with the Builder pattern. Could you provide a good example 
> of its use in a Go package?
> 
> On Mon, 25 May 2020, 06:25 robert engels,  > wrote:
> 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,
> 
>> On May 24, 2020, at 11:36 PM, Amarjeet Anand > > wrote:
>> 
>> Thanks James for your response and the amazing posts.
>> 
>> On Mon, May 25, 2020 at 9:01 AM James > > wrote:
>> 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 
>> 
>> On Mon, 25 May 2020 at 14:57, Amarjeet Anand > > wrote:
>> 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?
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 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+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
>>  
>> .
>> 
>> -- 
>> 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+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com
>  
> .

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CEC83E98-7E8C-4B01-AD72-565554DFE6A3%40ix.netcom.com.