I guess I cannot agree with you, Rick. I love the fact that Objective-C and now Swift require parameter names. I prefer verbose function names, parameters, etc.. than obtuse ones. I don't want to have to infer. I want it to be explicit. Infering types works because let myAttribString = NSMutableAttributableString() is very clear. That's my two cents.
On Wed, Jun 24, 2015 at 4:13 PM, Rick Mann <rm...@latencyzero.com> wrote: > > > On Jun 24, 2015, at 14:53 , Greg Parker <gpar...@apple.com> wrote: > > > > Swift's design is that the API author gets to choose what the call site > looks like. Allowing the caller to choose whether to specify names or not > hurts readability because of the inconsistency. It's bad for different > calls to the same method to look too different. > > I guess I disagree with this assertion. Generally, in a given body of > code, the usage will be consistent, and of course there are the billions of > lines of existing (C) code where no parameter names are specified. > > > If you as the author of a function think that the names are not useful, > or conversely think that the first parameter should also be named, then you > can write your function that way. Conversely, if you think the caller > should be allowed to specify names or not then you can write two overloads, > one of which simply calls the other. (I did something like this at one > point for CGRect's initializers, allowing any of CGRect(1, 2, 3, 4) or > CGRect(x:1, y:2, w:3, h:4) or CGRect(x:1, y:2, width:3, height:4). I don't > remember if that arrangement survived.) > > Again, this allows the author of the function to dictate, but not the > caller. > > We call many more functions than we write, so this increases the burden. > > The default naming rule is clearly a holdover from Objective-C, and really > seems to make little sense. If part of the argument is "most functions have > only one parameter," then I'd say the rule should be based on number of > parameters, not first-vs-rest. > > I strikes me as terribly inconsistent as it is, and terribly burdensome. I > *rarely* find improvement to naming the parameters at the call site. Maybe > I'm just better at naming the variables I pass as arguments. > > > On Jun 24, 2015, at 14:42 , Jens Alfke <j...@mooseyard.com> wrote: > > > > There isn’t always enough information, when there are optional > parameters. Without keywords it can be ambiguous which parameters have been > omitted. > > > > Also, can’t functions be overloaded by using different parameter names, > the way methods can? > > Which is why I was careful to state "If there's enough information > available…." Obviously if there is not (given the arguments and their types > supplied), then specifying one or more parameter names would be a fine way > to discriminate. > > But to ALWAYS require them is IMO not necessary. Why is it considered okay > to infer types? Wouldn't it be more clear if you had to specify types? I > don't see this discussion as substantially different. > > One possibility I raised in the Radar bug I filed was to make it an option > that can be passed to the compiler. If the call can be unambiguously > discriminated without parameter names, then the option would allow them to > be omitted. > > -- > Rick Mann > rm...@latencyzero.com > > > > _______________________________________________ > > 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/alex%40webis.net > > This email sent to a...@webis.net > -- *Alex Kac - **President and Founder* *Web Information Solutions, Inc.* _______________________________________________ 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
