On Jun 29, 2015, at 15:42 , Rick Mann <rm...@latencyzero.com> wrote:
>
> Here's an example (and this is what I frequently encounter) where requiring
> parameter names adds nothing but clutter:
>
> let config = WKWebViewConfiguration()
> self.webView = WKWebView(frame: self.webViewContainer.frame,
> configuration: config);
I’ve been thinking about this since yesterday, and while I don’t particularly
agree that the parameter names are extraneous in *this* case, I can think of a
couple of special cases:
1. If the function/method being called has extremely well-known parameters,
then I think I’d prefer the function to have a form that omits the names. In
particular, CGRect, CGPoint and CGSize:
> let rect = CGRect (x: 0, y: 0, width: 10, height: 10) // vs:
> let rect = CGRect (0, 0, 10, 10)
The point here is that the parameter semantics are known from the *name* of the
function, not from the actual parameters. We have this convention already, in
the default behavior where the first keyword to a regular function/method is
omitted:
> doSomethingWithRect (someRect)
This is similar to the CGRect initializer case, in that we know from the name
what the parameter is (because it tells us, in this case, not necessarily
because we knew it in advance).
2. There’s common situation where a variable name very often *is* a parameter
keyword. For example:
> init (frame: CGRect, configuration: WKWebViewConfiguration) {
> super.init (frame: frame, configuration: configuration)
> }
In this case, the name of the variable in the ‘super’ call *is* the same as the
keyword, because that’s a syntactic default in Swift. Under these
circumstances, I could see this being allowed:
> init (frame: CGRect, configuration: WKWebViewConfiguration) {
> super.init (frame, configuration)
> }
It may or may not be desirable to require that the keywords are all omitted or
all retained, or that this would only work for parameter variables (which have
a natural relationship to their keyword).
What do you think? This wouldn’t eliminate all the cases you’ve set your sights
on, but it would probably remove the most egregious ones. If there’s some
consensus here, I’ll file radars.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
