Leandro Lucarella wrote:
> Bill Baxter, el  6 de diciembre a las 16:58 me escribiste:
>> Janice Caron wrote:
>>> On Dec 5, 2007 1:48 PM, renoX <renosky@free.fr> wrote:
>>>> I could ask the opposite question: why should we restrict the API to the function and object name instead of using the full data that we have?
>>> I often write constructor functions which look something like this
>>>    this(int x_, int y_, int z_)
>>>    {
>>>        x = x_;
>>>        y = y_;
>>>        z = z_;
>>>    }
>>> If parameter names were part of the API, then anyone calling my code
>>> would have to refer to those constructor parameters as x_, y_ and z_,
>>> complete with trailing underscores
>>> Of course, I could go back and change all my code to
>>>    this(int x, int y, int z)
>>>    {
>>>        this.x = x;
>>>        this.y = y;
>>>        this.z = z;
>>>    }
>>> but that would be a lot of code to change, and it might break calling code!
>> That's why any named parameter proposal is going to have to flag the named parameters somehow.  Non-flagged parameters will continue to behave as always.
> 
> I don't see what's the big problem with named parameters being part of the
> API (when, by convention, you are told so). This is widely used on Python
> and works just great and it's damn useful.

In Python you cannot overload functions based on argument types. Keyword arguments help to fill the void that leaves.  So C++ and D don't need keyword args quite as badly as Python.

Also a D implementation probably would lack many of the features of Python's keyword args.  I doubt you would be able to do things like passing an AA as a set of keyword arguments.

I think in the end this is a feature that would be nice but
A) probably needs to be designed as part of the language from the beginning.
B) needs to be a pet peeve of the person writing the compiler.

--bb

Bill Baxter:
> Also a D implementation probably would lack many of the features of Python's keyword args.  I doubt you would be able to do things like passing an AA as a set of keyword arguments.

I presume a simpler semantics is enough for D; the * and ** semantic of parameter passing in Python 3.0 is probably a bit too much for D.

(And in the future that Python syntax with ** may be implmented too in SkedSkin, that translates a subset of Python to C++. I think the main problem isn't implementing its workings, but managing types: probably those function arguments (those dict values) are all of different type. Python dicts have no problem because it's a dynamically typed language, but D's AA are statically typed. So you may need an AA of Box[string]. Note that IronPython runs on dotnet, that has statically typed AAs, so thy have solved similar problems).

Bye,
bearophile

Janice Caron a écrit :
> On Dec 5, 2007 1:48 PM, renoX <renosky@free.fr> wrote:
>> I could ask the opposite question: why should we restrict the API to the function and object name instead of using the full data that we have?
> 
> I often write constructor functions which look something like this
> 
>     this(int x_, int y_, int z_)
>     {
>         x = x_;
>         y = y_;
>         z = z_;
>     }
> 
> If parameter names were part of the API, then anyone calling my code
> would have to refer to those constructor parameters as x_, y_ and z_,
> complete with trailing underscores

Would have?
No only could: nobody said that passing parameter by name should be mandatory.

As for the rest, yes having the possibility to pass parameter by name would mean that programmers will try to find better name for the parameters, but that's a plus if you believe in literate programming..

> Of course, I could go back and change all my code to
>     this(int x, int y, int z)
>     {
>         this.x = x;
>         this.y = y;
>         this.z = z;
>     }

I'm not sure that the trailing underscores would be that hurtful to the users..
Maybe such feature could be advertised 6 month before: "In 6 month, the name of your parameter will become visible to the users, please ensure that your parameters names are well-chosen."

> but that would be a lot of code to change, and it might break calling code!

Somehow Python, Ada manage to have this feature without issue, I've seen plenty of rants against both language but *never* read complaints against Python or Ada "passing parameter by name" feature..

renoX
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> To answer your question: passing parameter by name increase the readability of the source, reduce the number of mistake when writing the code (and with a good IDE the number of character to type would be the same).
>>
>>
>>> Named arguments are potentially a disastrous feature, if completely
>>> unrestricted. It was when COM needed to support VB's named arguments that
>>> Windows programming really nose-dived.
>> Could you explain this point? (I know nothing about COM).
>>
>>> (OTOH: A string mixin can, given the name of a function, tell you what the names
>>> of all of it's default arguments are (as well as what their default values are).
>>> I can in fact write a string mixin implementation of this feature; it's
>>> perfectly feasible. But is the concept actually a good idea?)
>> Note that passing parameter by name is only useful if programmers doesn't have to jump through hoops to do it, otherwise nobody will use it.
>>
>> renoX
>>