Re: Swift and parameter names
On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas mail...@xenonium.com wrote: Only because you are used to CGRect. QuickDraw used to defined a rect using left, top, right, bottom values. Actually, it was top, left, bottom, right. Charles ___ 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
Re: Swift and parameter names
On 1 Jul 2015, at 23:58, Charles Srstka cocoa...@charlessoft.com wrote: On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas mail...@xenonium.com wrote: Only because you are used to CGRect. QuickDraw used to defined a rect using left, top, right, bottom values. Actually, it was top, left, bottom, right. Charles And with that I believe the case for named parameters has been made. Named parameters is good syntax, autocomplete, which needs to still get better, makes writing it possibly easier than not, you have the parameter names filled-in for you and don’t need to engage brain at all. ___ 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
Re: Swift and parameter names
Le 30 juin 2015 à 23:46, Quincey Morris quinceymor...@rivergatesoftware.com
a écrit :
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)
Only because you are used to CGRect. QuickDraw used to defined a rect using
left, top, right, bottom values. Here you assume that your code reader is
already familiar with the API.
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/mailing%40xenonium.com
This email sent to mail...@xenonium.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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Swift and parameter names
On Jul 1, 2015, at 09:07 , Roland King r...@rols.org wrote: Named parameters is good syntax, autocomplete, which needs to still get better, It needs to get SO MUCH BETTER. • It still fails completely for me ALL the time, Xcode 6 or 7, there are times when it simply won't offer any completions at all • It still offers completions that are not appropriate in the context, making the list too long to search through. This is particularly troublesome if you can't remember the first few characters. • Worst thing: you can't type more past the first part of a function name. This is true for Obj-C and Swift. This is particularly bad when using delegates, since all delegates begin with the same prefix, the methods are only distinguished by parameter names. There's no way to type-select to reduce the length of a list of delegate names, and it can be quite hard to scan down the list to find the one that you really want, because there's no horizontal alignment of parameter names. Despite having filed bugs for all of this multiple times over the years, it hasn't gotten noticeably better. I'm especially surprised that last point hasn't been addressed. If instead, the (first part of) the function name carried the bulk of the name (rather than relying on parameter names), this would not be an issue. Moreover, you wouldn't be required to have an IDE that supports code completion (more of an issue with something like Swift being open-sourced and used in non-OS X environments). -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
On Jul 1, 2015, at 8:58 AM, Charles Srstka cocoa...@charlessoft.com wrote:
On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas mail...@xenonium.com wrote:
Only because you are used to CGRect. QuickDraw used to defined a rect using
left, top, right, bottom values.
Actually, it was top, left, bottom, right.
Classic Mac OS was inconsistent. For example, the C struct initializer for Rect
was { top, left, bottom, right }, but the initializer function was
SetRect(rect, left, top, right, bottom).
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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
Re: Swift and parameter names
On Jul 1, 2015, at 08:09 , Jean-Daniel Dupas mail...@xenonium.com wrote: Only because you are used to CGRect. Well, that’s kinda what I was saying: “everyone” is used to CGRect. I’ve been trying to think of other types that are as fundamental, but so far I haven’t thought of any beyond NS/CGRect/Point/Size Here you assume that your code reader is already familiar with the API. Yes, this is the counter-argument. As an alternative, I’ve been thinking about syntax coloring for keywords. You can sorta preview what this might look like by Command-hovering over a method name. (I find syntax coloring extremely helpful, but I know some people just find it distracting.) One other related issue is that Swift currently doesn’t have the Obj-C formatting ability of lining up parameter keyword colons vertically on multiple lines. I miss this greatly, because it was a good way of turning a jumble of keywords and expressions into something readable. Perhaps this feature will reappear in a future Swift. ___ 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
Re: Swift and parameter names
On 2 Jul 2015, at 11:15 am, Charles Srstka cocoa...@charlessoft.com wrote: and that you have the named function parameters to make it clear what’s going on Amen :) G. ___ 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
Re: Swift and parameter names
On 2 Jul 2015, at 7:22 am, Greg Parker gpar...@apple.com wrote:
Classic Mac OS was inconsistent. For example, the C struct initializer for
Rect was { top, left, bottom, right }, but the initializer function was
SetRect(rect, left, top, right, bottom).
Ah, the good old days /sarc
Obviously it’s only a convention, but I think horizontal values should always
precede vertical ones, if only because x comes before y in the alphabet, and
map coordinates are that way around as well. The change to {origin, size} was
also very welcome, if only because moving a rect is now independent from sizing
it, and doing either only changes two values, not four.
—Graham
___
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
Re: Swift and parameter names
On Jul 1, 2015, at 6:28 PM, Graham Cox graham@bigpond.com wrote:
Obviously it’s only a convention, but I think horizontal values should always
precede vertical ones, if only because x comes before y in the alphabet, and
map coordinates are that way around as well. The change to {origin, size} was
also very welcome, if only because moving a rect is now independent from
sizing it, and doing either only changes two values, not four.
From a mathematical point of view (which the NeXT-derived frameworks clearly
use), this is correct; the x-axis comes before the y-axis. However, from a more
general/intuitive point of view, I think you can make a pretty good case for
the vertical value coming first, given that in pretty much every situation in
ordinary life, we tend to process the vertical value first. When reading text
in Western languages, vertical position is more significant than horizontal,
and when we’re dealing with tabular data or pretty much anything that’s in a
grid-like arrangement, we always specify the row first, then the column.
This also explains why the classic Mac OS calculated vertical coordinates
starting from the top instead of the bottom — that is, after all, how we read,
and how we process most things that are spatially oriented; we start at the
top. Of course, mathematical coordinates go up from the x-axis, so that’s the
way the frameworks are set up.
Of course, in the end, it’s all convention, and it doesn’t really matter that
much as long as you’re consistent (and that you have the named function
parameters to make it clear what’s going on :-P).
Charles
___
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
Re: Swift and parameter names
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
Re: Swift and parameter names
On Jun 30, 2015, at 15:10 , Charles Srstka cocoa...@charlessoft.com wrote: This may be true for some cases, but I disagree with this particular example. Yes, you’re right. I simply zoned out when making up that name. I really meant something like ‘animateWithFrame’. However this example wasn’t to suggest anything new. I was just pointing out that we *already* omit the first keyword because by convention we know what it is from the method name. ___ 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
Re: Swift and parameter names
On Jun 30, 2015, at 4:46 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: 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). This may be true for some cases, but I disagree with this particular example. It is not at all clear what the parameters should be, simply by the name tells us it should be a rect. After all, there are multiple ways to define a rect with four numbers — the four parameters the classic Mac OS used to define a rect, for instance, were the positions of the top, left, bottom, and right edges. I’d say CGRect is definitely an instance where it seems intuitive because we’ve all been using NSMakeRect and the like for all these years, and we’re used to it. Charles ___ 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
Re: Swift and parameter names
On Jun 29, 2015, at 3:42 PM, 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); Moreover, when you're skimming the code, it looks a bit like the WKWebView constructor takes four arguments, not two. If you work the way I do, which is to skim pages of code for shapes (e.g., I know the constructor takes two parameters, so I can quickly zero in on a thing that looks like a call with a couple of parameters, delimited by white space, and then look more closely to see if it's the one I wanted. The extra islands of text from parameter names throws that off). Perhaps you would prefer a different whitespace convention, one with no spaces around the colon in actual parameters. That's a popular convention in Objective-C. Otherwise there is no difference between Objective-C and Swift here. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Re: Swift and parameter names
On Jun 29, 2015, at 15:50 , Greg Parker gpar...@apple.com wrote: Perhaps you would prefer a different whitespace convention, one with no spaces around the colon in actual parameters. That's a popular convention in Objective-C. Otherwise there is no difference between Objective-C and Swift here. I never really liked it in Objective-C, either. There's a big difference in that Swift is more like C, naming a function and then supplying the parameters in a parenthesized list. This, conceptually, makes the name and the parameter list more independent (overloading notwithstanding). And again, I'm just suggesting the compiler do its best to infer the parameter names instead of requiring them everywhere. Why not require variable types, as you suggested I provide when trying to diagnose the error? Surely that would made things more clear. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
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); If Code Completion worked 100% of the time, and responded in a millisecond, I might be able to get by using its reminders. But it fails to complete at least half the time for me, and take several hundred milliseconds to display options (I invoke it with a keystroke, I don't wait for the timer), and it often displays many more options than I need. I can't remember when a parameter name is required. So I write it without, then attempt to compile, then get told it's missing the frame name, so I add that, then figure I gotta add the config parameter, but I couldn't remember if it was config or configuration, so I had to wait for code completion, etc. Moreover, when you're skimming the code, it looks a bit like the WKWebView constructor takes four arguments, not two. If you work the way I do, which is to skim pages of code for shapes (e.g., I know the constructor takes two parameters, so I can quickly zero in on a thing that looks like a call with a couple of parameters, delimited by white space, and then look more closely to see if it's the one I wanted. The extra islands of text from parameter names throws that off). This happens ALL THE TIME. How often it happens that I really wish someone had named an unnamed parameter is never. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
On Jun 29, 2015, at 16:06 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Please stop Nice. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
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); Please stop. We already know what you think about this (from the last time you complained). This adds nothing. For every anecdotal example like this, there’s another one like this: self.webView = WKWebView(frame: rect, configuration: myParams); where it adds clarification, not clutter. If Code Completion worked 100% of the time, and responded in a millisecond […] Please stop. Code completion is crappy right now. It’s not a design flaw, it just isn’t finished yet. If you can’t handle that, stop using Swift until it’s more polished. Seriously, if it’s going to annoy *you* to the point where you keep annoying *us*, stick with Obj-C for another year. Moreover, when you're skimming the code, it looks a bit like […] Please stop. You can’t acquire the same familiarity with Swift in 2 months that you have with Obj-C over however many years it’s been. ___ 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
Re: Swift and parameter names
IMHO, named parameters at call sites are one of the things that makes Objective-C great; and I am VERY happy that Swift-2 enforces this. It is not any additional burden in any modern IDE to have this; as the IDE’s autocomplete fills in the parameter names for you. Also, consider a body of code that has inferred parameters in it… and now you need to add a new function; which makes the inferred call sites ambiguous. At best this will require some complicated regex replacement operations across the whole code base before it will compile again; at worst it will be unfixable (if you don’t have the source code and the binary that you are trying to link against doesn’t have enough information for the linker to resolve the ambiguity (I don’t know enough about Swift’s intermediate format to say if it does or not); or for some reason you do have the source code but are forbidden from modifying it). ___ 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
Re: Swift and parameter names
On 25 Jun 2015, at 16:50, dangerwillrobinsondan...@gmail.com wrote: On 2015/06/25, at 15:49, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: IMHO, named parameters at call sites are one of the things that makes Objective-C great; and I am VERY happy that Swift-2 enforces this. I agree whole heartedly. But will call out that it is a considered and thoughtful design by Cocoa and Foundation Framework engineers. Objective-C doesn't require it. Look at the old Next manual... There were a few obtuse methods. The IDE takes the burden of typing away. The conventions established help promote good coding practices that enable clarity and reduce mistakes and confusion. The (general) consistency and effort towards consistency those folks work towards is for everyone who codes to do it better. For themselves to more easily support developers consuming the APIs and end customers to have better quality products. I like where it ended up with Swift 2.0. In a vacuum I would possibly have gone for all parameters named and not 'all but the first one’ (with some exceptions for constructors) but I see how we got there and it does fit the transliteration of API from ObjC to Swift. And that standard transliteration, especially in the latest Swift, has made switching from ObjC to Swift much easier so I’m all for bringing that function naming convention over. I think one of the patterns I had to learn to make it work was naming functions like you do in objective C. I had no problem in that language doing -(Felony*)doSomethingWithJello:(Jello*)jello peaShooter:(PeaShooter*)peaShooter batmanMask:(BatmanMask*)batmanMask; when I first started writing Swift it looked like C to me, so my function name just became the verb and I got this func doSomething( jello : Jello, peaShooter : PeaShooter, batmanMask : BatmanMask )-Felony and when you have that it does’t make sense you don’t need to name the Jello. Once I started naming the functions in the same way I would have done the original objC one, it all made more sense func doSomethingWithJello( jello : Jello, peaShooter : PeaShooter, batmanMask : BatmanMask )-Felony On the odd occasion that I write more C-name-like functions then I usually double up the first parameter so they are all named when you call them. And if I have an initialiser which can only obviously take one argument, especially with generics where the argument is often ‘initialValue’, I underscore it away. 95% of the time I find I follow the conventions however and code is pretty readable. Similarly so is other people’s. ___ 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
Re: Swift and parameter names
On 2015/06/25, at 15:49, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: IMHO, named parameters at call sites are one of the things that makes Objective-C great; and I am VERY happy that Swift-2 enforces this. I agree whole heartedly. But will call out that it is a considered and thoughtful design by Cocoa and Foundation Framework engineers. Objective-C doesn't require it. Look at the old Next manual... There were a few obtuse methods. The IDE takes the burden of typing away. The conventions established help promote good coding practices that enable clarity and reduce mistakes and confusion. The (general) consistency and effort towards consistency those folks work towards is for everyone who codes to do it better. For themselves to more easily support developers consuming the APIs and end customers to have better quality products. ___ 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
Re: Swift and parameter names
On Jun 24, 2015, at 15:25 , Alex Kac a...@webis.net wrote: 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. Again, I'm just asking for the option. I'm not saying it should be removed from the language. Let me ask you this: do you also feel like you should specify variable types? -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Swift and parameter names
I'm really liking Swift 2, and after watching some of the WWDC2015 videos on the subject, I can't wait to use it in a real project. But one area where it REALLY bugs me is that external parameter names are required. I can see their utility, particularly with regard to a set of default values and being able to specify just the ones you care about (I'm pretty sure this worked in a quick test I did). I'm less convinced that using external parameter names in function calls improves readability or clarity. But I don't understand the need to require the use of external names at the call site. If there's enough information available to the compiler at the call site to unambiguously choose a function or method to call, why must I supply the parameter names? Why not let the caller choose which external names to specify, and only emit an error when the result is ambiguous? It's all complicated by the fact that the first parameter doesn't need to have an external name, but the rest default to having one, and it's the function definer who decides if they're required. I'm going to write a bug about this, but it seems Swift 2 is more strict than than Swift 1.2 (as evidenced by the examples in the Language Guide), so I don't see Apple reversing course on this (even though I think it can be done with zero impact on existing Swift 2 code). Thoughts? -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
On Jun 24, 2015, at 2:09 PM, Rick Mann rm...@latencyzero.com wrote: But I don't understand the need to require the use of external names at the call site. If there's enough information available to the compiler at the call site to unambiguously choose a function or method to call, why must I supply the parameter names? 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? —Jens ___ 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
Re: Swift and parameter names
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
Re: Swift and parameter names
As I wrote above, where you are assigning a type at that moment - no. Its quite obvious. You're doing it right there where its obvious. Frankly, I don't see the two things as being the two sides of the same coin. In one case the type is seen pretty obviously because you're assigning it. In the other you're passing arguments and its not obvious in most cases. On Wed, Jun 24, 2015 at 4:35 PM, Rick Mann rm...@latencyzero.com wrote: On Jun 24, 2015, at 15:25 , Alex Kac a...@webis.net wrote: 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. Again, I'm just asking for the option. I'm not saying it should be removed from the language. Let me ask you this: do you also feel like you should specify variable types? -- Rick Mann rm...@latencyzero.com -- *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
Re: Swift and parameter names
On Jun 24, 2015, at 2:09 PM, Rick Mann rm...@latencyzero.com wrote: I'm really liking Swift 2, and after watching some of the WWDC2015 videos on the subject, I can't wait to use it in a real project. But one area where it REALLY bugs me is that external parameter names are required. I can see their utility, particularly with regard to a set of default values and being able to specify just the ones you care about (I'm pretty sure this worked in a quick test I did). I'm less convinced that using external parameter names in function calls improves readability or clarity. But I don't understand the need to require the use of external names at the call site. If there's enough information available to the compiler at the call site to unambiguously choose a function or method to call, why must I supply the parameter names? Why not let the caller choose which external names to specify, and only emit an error when the result is ambiguous? It's all complicated by the fact that the first parameter doesn't need to have an external name, but the rest default to having one, and it's the function definer who decides if they're required. I'm going to write a bug about this, but it seems Swift 2 is more strict than than Swift 1.2 (as evidenced by the examples in the Language Guide), so I don't see Apple reversing course on this (even though I think it can be done with zero impact on existing Swift 2 code). Swift 2 established a single default naming rule for all methods and global functions. Swift 1 had two different rules which was confusing. The naming rule (first parameter un-named, additional parameters named) was chosen because it is the best fit with Cocoa methods and most one-argument functions. 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. 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.) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Re: Swift and parameter names
On Jun 24, 2015, at 15:43 , Alex Kac a...@webis.net wrote: As I wrote above, where you are assigning a type at that moment - no. Its quite obvious. You're doing it right there where its obvious. Frankly, I don't see the two things as being the two sides of the same coin. In one case the type is seen pretty obviously because you're assigning it. In the other you're passing arguments and its not obvious in most cases. I guess I disagree: it's obvious in most cases. Again, I'm just arguing for the OPTION. You can always choose to use the parameter name if you wish. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
On Jun 24, 2015, at 16:37 , Marco S Hyman m...@snafu.org wrote:
On Jun 24, 2015, at 4:09 PM, Rick Mann rm...@latencyzero.com wrote:
I guess I disagree: it's obvious in most cases. Again, I'm just arguing for
the OPTION. You can always choose to use the parameter name if you wish.
You have the option. Given this signature:
func foo(intArg: Int, stringArg: String) - Bool { ... }
add this code to call the function without named arguments.
func foo(intArg: Int, _ stringArg: String) - Bool {
return foo(intArg, stringArg: stringArg)
}
Now you can call it either way.
I like that I do NOT have the ability to mix and match calling conventions
by accident which could possibly confuse code readers. Especially when I am
the code reader! If I really need the the option to do mix styles adding
code such as that above wouldn’t be an issue.
Again, pretty huge burden.
--
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Swift and parameter names
On 25 Jun 2015, at 8:13 am, Rick Mann rm...@latencyzero.com wrote: 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. Reminds me of when I first learned a ‘proper’ structured language for the first time, back in the very early 1980s. I’d previously only known BASIC, for my sins. The idea that a function call like foo( a, b, c ) had an implicit mapping to variables within that function based solely on their listed order struck me as surprising and fragile. Of course I rapidly got used to that and it’s not really a problem, but I still recall the slight raising of the eyebrow it produced when I saw it for the first time. (I’m from the Roger Moore school of facial expressions). While we still have it in reality, naming the parameters is at least something like what I supposed I’d expected to see, back then. The ordering idea comes from the concept of a function in mathematics, so it’s not so strange, but I hadn’t realised that then. I suppose the only further generalisation would be that the order wouldn't matter, only the names would, but it’s likely impractical, a performance bottleneck, and a likely source of confusion, and would suggest that the only functions you may as well permit are like foo( Dictionary: params ); Short version: I like Obj-Cs approach, and very glad Swift is keeping the idea around. —Graham ___ 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
Re: Swift and parameter names
On Jun 24, 2015, at 4:09 PM, Rick Mann rm...@latencyzero.com wrote:
I guess I disagree: it's obvious in most cases. Again, I'm just arguing for
the OPTION. You can always choose to use the parameter name if you wish.
You have the option. Given this signature:
func foo(intArg: Int, stringArg: String) - Bool { ... }
add this code to call the function without named arguments.
func foo(intArg: Int, _ stringArg: String) - Bool {
return foo(intArg, stringArg: stringArg)
}
Now you can call it either way.
I like that I do NOT have the ability to mix and match calling conventions
by accident which could possibly confuse code readers. Especially when I am
the code reader! If I really need the the option to do mix styles adding
code such as that above wouldn’t be an issue.
Marc
___
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
Re: Swift and parameter names
On Jun 24, 2015, at 15:43 , Alex Kac a...@webis.net wrote: As I wrote above, where you are assigning a type at that moment - no. Its quite obvious. You're doing it right there where its obvious. Frankly, I don't see the two things as being the two sides of the same coin. In one case the type is seen pretty obviously because you're assigning it. In the other you're passing arguments and its not obvious in most cases. You're not assigning a type at the moment. It's no more obvious than passing a variable as an argument. var someNewVar = someOldVar How is that any more obvious than what's going on at a call site? -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Swift and parameter names
code such as that above wouldn’t be an issue. Again, pretty huge burden. Only a burden to one who wants the ability to call functions or methods with or without argument names. Many (most?) are not asking for that ability. ___ 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
Re: Swift and parameter names
On Jun 24, 2015, at 14:53 , Greg Parker gpar...@apple.com wrote: Swift 2 established a single default naming rule for all methods and global functions. Swift 1 had two different rules which was confusing. The naming rule (first parameter un-named, additional parameters named) was chosen because it is the best fit with Cocoa methods and most one-argument functions. Is there a difference between init() and func...? I'm getting a warning for a func I wrote: Extraneous '_' in parameter: 'inX' has no keyword argument name But not for the init() method with the same signature. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
