Jump to content

Named parameter: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Tag: nowiki added
Line 36: Line 36:


An added complication arises in languages such as [[OCaml]] that support both optional named parameters and [[partial application]]. It is impossible in general to distinguish between a function partly applied, and a function to which a subset of parameters have been provided. OCaml resolves this ambiguity by requiring a positional parameter after all optional named parameters: its presence or absence is used to decide if the function has been fully or partly applied. If all parameters are optional, the implementor may solve the issue by adding a dummy positional parameter of type [[Unit type|unit]].
An added complication arises in languages such as [[OCaml]] that support both optional named parameters and [[partial application]]. It is impossible in general to distinguish between a function partly applied, and a function to which a subset of parameters have been provided. OCaml resolves this ambiguity by requiring a positional parameter after all optional named parameters: its presence or absence is used to decide if the function has been fully or partly applied. If all parameters are optional, the implementor may solve the issue by adding a dummy positional parameter of type [[Unit type|unit]].

In [[MediaWiki]], the codes (variables) <code><nowiki>{{{1}}}</nowiki></code>, <code><nowiki>{{{2}}}</nowiki></code> in templates and so on, will be replaced by the first, second, and so on ''unnamed parameter'' (or the value of a parameter named <code>1</code>, <code>2</code>, etc.); these are known as ''{{dfn|positional parameter}}s.


== Emulating ==
== Emulating ==

Revision as of 13:46, 8 May 2020

In computer programming, named parameters, named argument or keyword arguments refer to a computer language's support for function calls that clearly state the name of each parameter within the function call.

Overview

A function call using named parameters differs from a regular function call in that the values are passed by associating each one with a parameter name, instead of providing an ordered list of values.

For example, consider this Java method call using no named parameters:

window.addNewControl("Title", 20, 50, 100, 50, true);

Using named parameters in Python, the call can be written as:

window.addNewControl(title="Title",
                     xPosition=20,
                     yPosition=50,
                     width=100,
                     height=50,
                     drawingNow=true)

The Java version is more implicit. The Python version is more explicit. Depending on a given instance, a programmer may find one or the other easier to read.

Use in programming languages

Named parameters are supported explicitly in many languages. A non-exhaustive selection of examples includes Ada, C# 4.0+, Ceylon, ColdFusion Markup Language (CFML), Common Lisp, Fortran, IDL, Kotlin, Mathematica, PL/SQL, PowerShell, Python, R, Ruby, Scala, Smalltalk, Swift[1] and Visual Basic. Note that Objective-C does not have named parameters (even though parts of the method name may look like named parameters).[2]

Order of parameters

In languages with no named parameters, the order of parameters in a function call is necessarily fixed, since it is the only way that the language can identify which value is intended to be used for which purpose.

With named parameters, it is usually possible to provide the values in any arbitrary order, since the name attached to each value identifies its purpose. This reduces the connascence between parts of the program. A few languages use named parameters but still require the parameters to be provided in a specific order.

Optional parameters

Named parameters are often used in conjunction with optional parameters. Without named parameters, optional parameters can only appear at the end of the parameter list, since there is no other way to determine which values have been omitted. In languages that support named optional parameters, however, programs may supply any subset of the available parameters, and the names are used to determine which values have been provided.

An added complication arises in languages such as OCaml that support both optional named parameters and partial application. It is impossible in general to distinguish between a function partly applied, and a function to which a subset of parameters have been provided. OCaml resolves this ambiguity by requiring a positional parameter after all optional named parameters: its presence or absence is used to decide if the function has been fully or partly applied. If all parameters are optional, the implementor may solve the issue by adding a dummy positional parameter of type unit.

In MediaWiki, the codes (variables) {{{1}}}, {{{2}}} in templates and so on, will be replaced by the first, second, and so on unnamed parameter (or the value of a parameter named 1, 2, etc.); these are known as positional parameters.

Emulating

In languages without named parameters, some of the same benefits can be achieved in other ways.

With documentation

Their value as documentation can be replicated by tooltips in integrated development environments (IDEs) for languages such as Java, or with comments (in C):

MyFunctionCall(
    20,  /* x coordinate */
    50,  /* y coordinate */
    100, /* width */
    5,   /* height */
    TRUE /* drawing now? */
);

But this provides no checking, and the order of arguments remains important.

With data structures

Removing the argument order restriction, and the ability to leave some values unspecified, can be achieved by passing a record or associative array.

For example, in JavaScript, these two calls are equivalent:

MyFunctionCall({ xPosition: 20, yPosition: 50, width: 100, height: 5,
                 drawingNow: true });
MyFunctionCall({ width: 100, height: 5, xPosition: 20, yPosition: 50,
                 drawingNow: true });

Compare to C99:[3]

struct MyParam {
    int xPosition;
    int yPosition;
    int width;
    int height;
    unsigned char drawingNow;
};

MyParam parameters = { .xPosition = 20, .yPosition = 50,
        .width = 100, .height = 5, .drawingNow  = TRUE };
MyFunctionCall(&parameters);

In Perl, a similar convention exists. Functions with long parameter lists often accept an associative array (named a hash in Perl) that contains some or all parameters.[4] As an example, the core module's Net::FTP new function accepts a hash of optional arguments.[5]

With chained method calls

In object-oriented programming languages, it is possible to use method chaining to simulate named parameters, as a form of fluent interface. Each named parameter is replaced with a method on a parameter object that modifies and then returns the object. In C++, this is termed the named parameter idiom.[6] The object may then be passed to a function that uses the parameters it contains.

Method chaining is often used in conjunction with the builder pattern as a way to override default values provided by the builder class.

See also

References

  1. ^ "Functions — The Swift Programming Language (Swift 5.1)". docs.swift.org. Retrieved 2020-01-27.
  2. ^ Developer Library - The Implementation of a Class Provides Its Internal Behavior
  3. ^ https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
  4. ^ Perl Design Patterns TinyWiki, NamedArguments
  5. ^ Perl core module Net::FTP
  6. ^ C++ FAQ, 10.20 What is the "Named Parameter Idiom"?