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, <[email protected]> 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 <[email protected]>
> wrote:
>
> Thanks James for your response and the amazing posts.
>
> On Mon, May 25, 2020 at 9:01 AM James <[email protected]> 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 <
>> [email protected]> 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 [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com
> <https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.com?utm_medium=email&utm_source=footer>
> .
>

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

Reply via email to