Reinforcing comments above: defaults are not *missing*, they have been
*avoided*. One can argue default arguments are either a mistake in API
design or neglect in code refactoring.
On the mistake side, the argument is that making "cook(n)" mean "make pizza
if n is missing or cook n if otherwise" adds complexity of comprehension in
exchange for simplicity of expression. Use of varadic arguments does not
change this view that the savings are a deferred cost. As a program user,
extender, debugger, or reviewer, the idea is that you would rather see
cookPizza() and cook(food) in the code, and of course, cookPizza() would
just be cook("pizza"), the inliner would do this in compilation, and the
effect would be as if a default, but the code would be more plain, more
descriptive, and less surprising.
As for refactoring, one need not look far to find an existing C++ API to
which has been added some last-minute parameter, defined as nil or default,
but which allows invisible insertion of new functionality not previously
provided. That is so seductive that most of us have done it. Unfortunately,
it also means that all the old call sites have a hidden secret not visible
to those who read the code. This has proven to be a source of woe. Better
is to refactor the API to best express the new truth and feature set.
These are not "get it to work by yourself" concerns, they are "keep it
working and use it across teams" issues. The notions of Go favor the latter.
On Fri, Aug 24, 2018 at 7:59 AM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:
> The distinction you are missing is that Go only considers the *name* of
> an interface method to be unique, meaning only one parameter definition is
> allowed per name. What this means is that in Go these have to be separate
> functions and by definition, differently named. This is why I am suggesting
> that a method of structuring complex objects that is used extensively in
> the standard library is the solution -
>
>
> - you create a function with some set of defaults and no parameter
> - then appropriately named functions
> - and all functions that return no specific other values return the
> pointer to the receiver
>
> Then you can have the same result as only needing to specify parameters
> that differ from defaults, but with the aditional benefit you can create
> multiple configurations for initialisation, loading, copying and
> transferring in from other types especially if they are same as members or
> commutable to members of the receiver type.
>
> On Friday, 24 August 2018 15:15:28 UTC+2, Robert Johnstone wrote:
>>
>> Hello,
>>
>> This is misleading. With default arguments, there remains only one
>> function definition, which makes it quite different from function
>> overloading where there would be multiple definitions. Default parameters
>> provides syntax sugar at the call site, but does not create additional
>> functions.
>>
>> I'm not arguing for default parameters. The explanation in
>> https://talks.golang.org/2012/splash.article#TOC_10 is good, given Go's
>> philosophy.
>>
>> Robert
>>
>>
>> On Thursday, 23 August 2018 19:26:36 UTC-4, Ian Lance Taylor wrote:
>>>
>>> On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani
>>> <msud.g...@gmail.com> wrote:
>>> > I didn't get the relation of function overloading with parameters
>>> default
>>> > value. actually, function overloading means define functions with
>>> similar
>>> > names.
>>>
>>> Right. After adding a default value for the parameter, you have two
>>> functions with similar names:
>>> F(int)
>>> F()
>>>
>>> It's exactly as though you overloaded F.
>>>
>>> Ian
>>>
>>>
>>> > On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor
>>> wrote:
>>> >>
>>> >> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani
>>> >> <msud.g...@gmail.com> wrote:
>>> >> >
>>> >> > Your opinion is like to say all of the python application should
>>> rethink
>>> >> > and
>>> >> > re-write their structure because they used default values. I think
>>> >> > having
>>> >> > default values for parameters is just a feature which will make
>>> codebase
>>> >> > readable and smaller than before.
>>> >>
>>> >> Default values for parameters is in effect a simple form of function
>>> >> overloading. If F(int) has a default value for the parameter, then
>>> >> you've overloaded F with another function F() that takes no
>>> arguments.
>>> >> Go doesn't have function overloading in general, and it doesn't have
>>> >> default parameter values either.
>>> >>
>>> >> Ian
>>> >
>>> > --
>>> > 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.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@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.
For more options, visit https://groups.google.com/d/optout.
