Pretty please: Named arguments

[Emil Madsen]

On 9 March 2011 13:22, Gareth Charnock <gareth.charnock at gmail.com> wrote:

> Named arguments are useful when you have a function that takes a large
> number of parameters, the vast majority of which have default values. For
> example, have a look at this constructor in wxWidgets:
>
>
> http://docs.wxwidgets.org/trunk/classwx_frame.html#01b53ac2d4a5e6b0773ecbcf7b5f6af8
>
> wxFrame::wxFrame        (       wxWindow *      parent,
> wxWindowID      id,
> const wxString &        title,
> const wxPoint &         pos = wxDefaultPosition,
> const wxSize &  size = wxDefaultSize,
> long    style = wxDEFAULT_FRAME_STYLE,
> const wxString &        name = wxFrameNameStr
> )
>
> If you want to change the name argument you need to call
>
> new wxFrame(a_parent,wxANY,"Hello
> world",wxDefaultPosition,wxDefaultSize,wxDEFAULT_FRAME_STYLE,"My Custom name
> str")
>
> Which meant I had to look up what the default values of pos,size and style
> where even though I was happy with those default values. The more arguments
> the more of a pain this setup is without named arguments. Contrast to a
> hypothetical C++ syntax:
>
> new wxFrame(a_parent,wxANY,"Hello world",name = "My Custom name str")
>
> I haven't bothered with the arguments I don't care about and my function
> call has ended up less sensitive to changes in the wxFrame constructor.
>
>
> On 28/02/11 21:50, Jonathan M Davis wrote:
>
>> On Monday, February 28, 2011 13:38:34 Don wrote:
>>
>>> spir wrote:
>>>
>>>> On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
>>>>
>>>>> I'm not entirely against named arguments being in D, however I do
>>>>> think that any
>>>>> functions that actually need them should be refactored anyway.
>>>>>
>>>>
>>> I agree.
>>> CreateFont() in the Windows API, I'm looking at you. (For Linux people,
>>> that function has about 12 parameters).
>>>
>>>  ???
>>>>
>>>>  In actuality, if I were to vote on whether named arguments should be
>>>>> in the
>>>>> language, I would definitely vote against it (I just plain don't want
>>>>> the code
>>>>> clutter,  [...]
>>>>>
>>>>
>>>> Just don't use them!
>>>>
>>>
>>> You don't have that option. At least, if you're a library developer, you
>>> don't. (I'm a bit sick of people saying "you don't have to use it if you
>>> don't want to" in language design. If it is in the language, you don't
>>> have a choice. You will encounter it).
>>>
>>> There are a couple of things that I really, really don't like about the
>>> names argument idea:
>>> 1. It makes parameter names part of the API.
>>> Providing no way for the function writer to control whether it is part
>>> of the API or not, and especially, doing it retrospectively, strikes me
>>> as extremely rude.
>>>
>>> 2. It introduces a different syntax for calling a function.
>>> foo(4, 5);
>>> foo(x: 4, y: 5);
>>> They look different, but they do exactly the same thing. I don't like
>>> that redundancy.
>>>
>>>
>>> Especially since, as far as I can tell, the named arguments are just
>>> comments (which the compiler can check).
>>> If so, a syntax like this would be possible, with no language change at
>>> all:
>>>
>>> pragma(namedarguments); // applies to whole module
>>>
>>> foo(/*x*/ 4, /*y*/ 5);
>>>
>>> --->  if a function parameter has a comment which forms a valid
>>> identifier, it's a named parameter.
>>>
>>> But I still don't see the need for this feature. Aren't people using
>>> IDEs where the function signature (with parameter names) pops up when
>>> you're entering the function, and when you move the mouse over the
>>> function call?
>>> And if you really want to see them all the time, why not build that
>>> feature into the IDE?
>>> ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
>>>
>>
>> I agree with pretty much everything said here. However, as I understand
>> it,
>> named parameters (at least as they work in Python) would allow for you to
>> reorder parameters and give values for paramters which are normally
>> default
>> parameters without giving values for the default paramters before them,
>> and
>> those changes could not be dealt with by comments. However, I consider
>> them to
>> be a big _problem_, not a feature - _especially_ the ability to rearrange
>> the
>> function arguments. All of a sudden you could have
>>
>>
>> foo(4, 5);
>> foo(x : 4, y : 5);
>> foo(y : 5, X : 4);
>>
>> all making _exactly_ the same function call. That seem _very_ bug-prone
>> and
>> confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5,
>> x :
>> 4)? Not good. The amount of effort to understand the code becomes
>> considerably
>> higher. You could be very familiar with foo and know exactly what
>> parameters it
>> takes and totally mistake what it's really getting passed, because the
>> arguments
>> were flipped in comparison to the function parameters.
>>
>> I agree with Don. I think that named parameters would cause far more
>> intellectual overhead and problems than they'd solve.
>>
>> - Jonathan M Davis
>>
>> - Jonathan M Davis
>>
>
>
I actually like the idea of named variables, for these funktions that takes
a lot of parameters, mostly because if the libary dev, chooses to change the
default value of something, my old placeholder value, will end up being
wrong without me knowing anything about it.

Say:
wxFrame::wxFrame        (       wxWindow *      parent,
wxWindowID      id,
const wxString &        title,
const wxPoint &         pos = wxDefaultPosition,
const wxSize &  size = wxDefaultSize,
long    style = wxDEFAULT_FRAME_STYLE,
const wxString &        name = wxFrameNameStr
)

And I call it with the default args, because I have to, to change the name;
however then the libary dev decides it would be better to have a default
value of size = 800x600, now I'm not getting the default as I wanted to.


-- 
// Yours sincerely
// Emil 'Skeen' Madsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110309/4a53c356/attachment-0001.html>