1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
# Keyword Arguments in Java
## What
Java arguments are traditionally passed by position:
void foo(int x, int y, int z)
matches the call
foo(1, 2, 3)
and assigns `1` to `x`, `2` to `y`, and `3` to `z` in the resulting
activation. Keyword arguments assign values to formal parameters by matching
the parameter's name, instead.
## Why
Fuck the builder pattern, okay? Patterns like
Response r = Response
.status(200)
.entity(foo)
.header("X-Plane", "Amazing")
.build();
(from JAX-RS) mean the creation and maintenance of an entire separate type
just to handle arbitrary ordering and presence/absence of options. Ordering
can be done using keywords; presence/absence can be done by providing one
method for each legal combination of arguments (or by adding optional
arguments to Java).
The keyword-argument version would be something like
Response r = new Response(
.status = 200,
.entity = foo,
.headers = Arrays.asList(Header.of("X-Plane", "Amazing"))
);
and the `ResponseBuilder` class would not need to exist at all for this case.
(There are others in JAX-RS that would still make `ResponseBuilder` mandatory,
but the use case for it gets much smaller.)
As an added bonus, the necessary class metadata to make this work would also
allow reflective frameworks such as Spring to make sensible use of the
parameter names:
<bean class="com.example.Person">
<constructor-arg name="name" value="Erica McKenzie" />
</bean>
## Other Languages
Python, most recently:
def foo(x, y, z):
pass
foo(z=3, x=1, y=2)
Smalltalk (and ObjectiveC) use an interleaving convention that reads very much
like keyword arguments:
Point atX: 5 atY: 8
## Challenges
* Minimize changes to syntax.
* Make keyword arguments unambiguous.
* Minimize changes to bytecode spec.
## Proposal
Given a method definition
void foo(int x, int y, int z)
Allow calls written as
foo(
SOME-SYNTAX(x, EXPR),
SOME-SYNTAX(y, EXPR),
SOME-SYNTAX(z, EXPR)
)
`SOME-SYNTAX` is a production that is not already legal at that point in Java,
which is a surprisingly frustrating limitation. Constructs like
foo(x = EXPR, y = EXPR, z = EXPR)
are already legal (assignment is an expression) and already match positional
arguments.
Keyword arguments match the name of the formal argument in the method
declaration. Passing a keyword argument that does not match a formal argument
is a compilation error.
Calls can mix keyword arguments and positional arguments, in the following
order:
1. Positional arguments.
2. Varargs positional arguments.
3. Keyword arguments.
Passing the same argument as both a positional and a keyword argument is a
compilation error.
Call sites must satisfy every argument the method/constructor has (i.e., this
doesn't imply optional arguments). This makes implementation easy and
unintrusive: the compiler can implement keyword arguments by transforming them
into positional arguments. Reflective calls (`Method.invoke` and friends) can
continue accepting arguments as a sequence.
The `Method` class would expose a new method:
public List<String> getArgumentNames()
The indexes in `getArgumentNames` match the indexes in `getArgumentTypes` and
related methods.
Possibilities for syntax:
* `foo(x := 5, y := 8, z := 2)` - `:=` is never a legal sequence of tokens in
Java. Introduces one new operator-like construct; the new sequence `:=`
“looks like” assignment, which is a useful mnemonic.
* `foo(x ~ 5, y ~ 8, z ~ 2)` - `~` is not a binary operator and this is never
legal right now. This avoids introducing new operators, but adds a novel
interpretation to an existing unary operator that's not related to its
normal use.
* `foo(.x = 5, .y = 8, .z = 2)` - using `=` as the keyword binding feels more
natural. Parameter names must be legal identifiers, which means the leading
dot is unambiguous. This syntax is not legal anywhere right now (the dot
always has a leading expression). The dot is a “namespace” symbol already.
To support this, the class file format will need to record the names of
parameters, not just their order. This is a breaking change, and generated
names will need to be chosen for existing class files. (This may be derivable
from debug information, where present.)
## Edge Cases
* Mixed positional and keyword arguments.
* Collisions (same argument passed by both) are, I think, detectable at
compile time. This should be an error.
* Inheritance. It is legal for a superclass to define `foo(a, b)` and for
subclasses to override it as `foo(x, y)`. Which argument names do you use
when?
* Varargs.
|
