Associative parameters

Pragma ericanderton at yahoo.removeme.com
Tue Jul 10 13:34:56 PDT 2007


Bill Baxter wrote:
> Greg wrote:
>> Walter Wrote:
>>
>>> "Sefan Zobel" <Sefan_member at pathlink.com> wrote in message
>>> news:d9n5i9$aad$1 at digitaldaemon.com...
>>>> In article <d9lnrr$26q3$1 at digitaldaemon.com>, Chris Sauls says...
>>>>> In python, you would do something like this:
>>>>>
>>>>> # foo (
>>>>> #   x = someX ,
>>>>> #   y = someY ,
>>>>> #   z = someZ
>>>>> #   )
>>>>>
>>>>> Now isn't that just nifty?
>>>>
>>>> This is also called "named parameters" in some languages (since 
>>>> parameters
>>>> are resolved by name, not by position). And, yes, I like it too :)
>>> Named parameters are problematic when overloading is thrown into the 
>>> mix.
>>>
>>>
>> What is problematic? I used named parameters with Ada and I'm not 
>> aware of any problems with it.
>> In addition to making the code easier to read, named parameters avoid 
>> the burden of creating "dummy" functions when some parameters are 
>> optional.
>> I found nothing on the net telling that python's or ada's 
>> implementation of named parameters is problematic.
>> Can someone confirm/infirm on this point?
> 
> I don't know about Ada, but Python doesn't have function overloading.
> A given module can only have one function called 'foo'.

Just my $0.02 here: Lately I have been doing a lot more python programming and I've found it's named arguments to be a 
good substitute for overloading.  It's not perfect replacement, but it does have its advantages.  I have yet to find it 

problematic.

I can't speak for Ada though.

FWIW, ColdFusion script also offers named arguments, but it takes the all-or-nothing approach; if you name one arg, you 
must name all that you pass.  IMO, the python strategy (positional followed by named arguments) is much more intuitive.

But from what I can tell, named arguments are no more or less problematic than overloads mixed with default arguments. 
Right now, it's possible to create two or more overloads that can be called the same way, resulting in an ambiguity that 
is easily flagged by the compiler.  Named arguments just provide another way to make the same kind of mistake, so the 
developer must be no more aware than before.

void foobar(int d);
void foobar(int a=0,int b=0,int c=0,int d=0);
foobar(d=42); // which one?
foobar(69);   // which one?



> 
> But I do recall reading an essay/rant somewhere talking about how 
> sometimes just picking one way to do something makes life easier for 
> everyone, and the handling of function overloading was mentioned.  I 
> think it mentioned Ada's way and Python's way specifically. 
> Unfortunately I can't seem to find it now.
> 
> --bb


-- 
- EricAnderton at yahoo



More information about the Digitalmars-d mailing list