On 2/28/11 1:32 AM, Russel Winder wrote:
The huge downside of any named parameter approach is that you have data
coupling between the source of the callee and the caller. This is fine
in a language such as Python where you distribute source and
documentation tools so you can always find out the names of parameters,
this is going to be a bit of a problem in languages where only the
compiled form may be the only distributed form. Programmers rely on
some other form of documentation other than the source and this leads to
error,
It's not all that bad. Walter and I discussed a couple of times adding
such a feature. As long as the function signature in the .d or .di file
does specify a parameter name, that can be used.
Potential problems: The only problems I can foresee here are variations
on the situation when there are two (or more) versions of a function
with the same number, type, and names of parameters, but in non-matching
order, like this:
void func(int a, char b);
void func(char b, int a);
In such a case, the compiler should diagnose an error if named arguments
are employed.
Thoughts?
The Python mechanism relies on the fact that despatch is by name and not
by signature. Languages that dispatch by signature will have
significantly greater problems!
A good subset of Python's approach to parameter passing sugar can be
done without using maps or dispatch by name.
Andrei
