Talk:Named parameters

From Rosetta Code
Revision as of 15:12, 4 July 2009 by rosettacode>Kevin Reid (3 kinds of tasks...)

Duplication?

You don't seem to have adequately expressed the difference between this task and Varargs/Optional parameters. If you take away the TCL example, what is left? Is the task to show arguments being given in a call in a different order to that of the definition? Are default values necessary? Do we need to overhaul all three tasks and work out what aspects of function arguments we need to show/how many tasks to do it? --Paddy3118 05:58, 29 June 2009 (UTC)

There is some duplication, yes, but it seems that the Optional parameters task was written by someone who wasn't aware of the possibility of optional positional parameters, which some languages support, so leaving that task still ambiguously defined. I'm trying to decompose features in this area so that these assumptions are teased out, and the naming of parameters is actually independent of supporting variable numbers of them (witness Objective C). Another justification for having them separate is that being able to set parameters by name leads to a different, far more literate programming style to setting them purely by position.
Also note that the Tcl example in the Optional parameters task is wrong; there's another mechanism (optional positional parameters) that should be demonstrated there instead. I'll have to correct that. Bother… —Donal Fellows 07:56, 29 June 2009 (UTC)
When I wrote Optional parameters it was my intent that positional optional parameters were included in it; the text even says so. It was designed to be accomplished in many different ways (as opposed to, say, this task, which specifies the particular concept of named parameters).
I am concerned that the idea you mention of "decomposition" of features leads to many tasks which demonstrate single language features/properties, and entirely leave out languages which simply do not have those features -- and the whole point of RC is comparative programming, so this is undesirable; we should aim to have tasks which many languages can implement, using their own particular facilities. --Kevin Reid 13:39, 4 July 2009 (UTC)
So Kevin, would a task of "Function definition/Function call semantics and examples" be too wide a task? You might have noticed that after my initial question above, I thought it might be best to write something that might cover all such tasks and linked the Python entries of the other two to this one. --Paddy3118 13:55, 4 July 2009 (UTC)
Such a task is a different kind of thing, "explain your language" rather than "implement this specification". I agree that such tasks should exist (e.g. I wrote Eval and Variables), but they should be considered separately from "implement this specification" tasks like Optional parameters. Named Arguments I would say falls into a third category, along with e.g. List Comprehension: "given that your language has this feature, tell us about your particular variation".
In the course of writing this comment, I have changed my position: that third category is in fact valuable, and named arguments are a significant enough feature that they should have a task which focuses on them (e.g. comparing Common Lisp vs. Python vs. Objective-C would be enlightening as to the variations possible).
I still think that there are too-narrow tasks: for example the basic loop tasks in Category:Iteration are such because they assume a particular family of iteration facilities: once you've been that specific, there is no room for interesting variation between languages, just syntax. --Kevin Reid 15:12, 4 July 2009 (UTC)