Re: Swift and parameter names
Re: Swift and parameter names
- Subject: Re: Swift and parameter names
- From: Alex Kac <email@hidden>
- Date: Wed, 24 Jun 2015 16:25:24 -0600
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 <email@hidden> wrote:
>
> > On Jun 24, 2015, at 14:53 , Greg Parker <email@hidden> 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 <email@hidden> 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
> email@hidden
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
--
*Alex Kac - **President and Founder*
*Web Information Solutions, Inc.*
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden