On Sep 7, 2022, at 1:41 PM, Brian Goetz
<[email protected]<mailto:[email protected]>> wrote:
. . .
Where we stumble is on method parameters, because method parameter names serve
two masters -- the implementation (as the declaration of a variable) and the
API (as part of the specification of what the method does.) Among other
things, we like to document the semantics of method parameters in Javadoc with
the `@param` tag, but doing so requires a name
And a general language-design pattern is that if you discover a single language
feature is serving two masters, consider splitting it into two features, one to
serve each master (and then perhaps continue to allow the old feature,
explaining it in terms of the new, more general features.
In this case, a single feature (method parameter name) provides both a name for
the implementation and a name for the API. So, consider having a way to provide
two names. Common Lisp has been doing this for its keyword parameters for
almost four decades:
(defun foo (&key ((:color c) white) ((:angle a) 0))
… c … a …)
(foo :color black :angle 45)
So the names :color and :angle are part of the API, and the names c and a are
the variable names that are actually bound for use in the body.
When you write
(defun baz (&key (color white) (angle 0))
… color … angle)
it is by definition an abbreviation for
(defun baz (&key ((:color color) white) ((:angle angle) 0))
… color … angle)
So you don’t have to write out two names in the common case where you actually
do want them to be “the same”.
————
So in Java we could pick some crazy syntax to allow specifying two names for a
method parameter, the API name and the implementation (bound variable) name:
int colorHack(int red=>r, int green=>g, int blue=>b, int fromIndex=>from, int
toIndex=>to) {
// Here the names `r`, `g`, `b`, `from`, and `to` are in scope.
}
and then if you really want to ignore a parameter:
int colorBlindHack(int red=>_, int green=>_, int blue=>_, int fromIndex=>from,
int toIndex=>to) {
// Here the names `from` and `to` are in scope.
}
Not sure we want to go in that direction, but we should at least consider it.
—Guy
