4 ms·

I hope they do adopt that suggested change to method calls. Swift is a nice language, but there's still some awkwardness due to its required compatibility with

by TillE 11y ago

I hope they do adopt that suggested change to method calls. Swift is a nice language, but there's still some awkwardness due to its required compatibility with Objective C. I think if you don't come from that background, then having all named arguments except the first one seems really arbitrary and nonsensical.

ChrisLTD 11y ago
I would screw up that first named argument thing every time if it weren't for Xcode's autocomplete.
ceeK 11y ago
To be honest, even as a fairly seasoned iOS developer I still prefer to have a non-optional first argument in my APIs. Whereas the post's example compares: path.addLineToPoint(CGPoint(x: 100, y: 0)) -- to -- path.addLineTo(CGPoint(x: 100, y: 0)) I've been doing it as so: path.addLine(toPoint: CGPoint(x: 100, y: 0)) ...requiring the "toPoint", which can swapped out true method overloading style: path.addLine(toArc:...) In your internal method implementation, Swift allows you to replace the external method name with an internal one, so that it's still nice to work with: func addLine(toPoint point: CGPoint) { ... } I personally think it's a lot more readable. Otherwise the first argument has to have a really descriptive class name (recommended for sure, but often not the case).
- seivan 11y ago
  Yup, that's what I would like. It's silly to remove the point from the method name and not makes it into a named argument that could be overloaded for others. I might just do that for my own stuff. I don't like the notion of the first argument not being in either the method name or as a named argument.
- nardi 11y ago
  The point here (no pun intended) is to stop repeating noun phrases at the call site. Your call site says "point" twice for no reason: path.addLine(toPoint: CGPoint(x: 100, y: 0)) See the "toPoint: CGPoint". It's useless repetition. The new form eliminates it: path.addLineTo(CGPoint(x: 100, y: 0)) It's clear you're adding a line to a point, because it says "Point" right there. Even if you have a variable for this point already, it works great: path.addLineTo(point) Or maybe this is a more specifically named point? path.addLineTo(centerPoint) It's clear from all that you're adding a line to a point. Swift has an emphasis on concise syntax, and removing the repetition, IMO, is a nice win in readability.
  - ceeK 11y ago
    You do have a good point, and something I didn't explicitly notice before. This does seem to have the indirect consequence of enforcing some sort of type information in the variable name, but I expect many iOS developers do that regardless. It'd also be interesting to see the impact on readability when you have longer variable names. `point` definitely makes it more concise here. But if you had several points within the same scope, readability may suffer given type information is typically at the end of a variable name? path.addLineTo(childViewTopLeftPoint) path.addCurveTo(childViewTopRightPoint, withControlPoint1: arbitrary1Point, andControlPoint2: arbitrary2Point) path.addLine(toPoint: childViewTopLeftPoint) path.addCurve(toPoint: childViewTopRightPoint, withControlPoint1: arbitrary1Point, andControlPoint2: arbitrary2Point) I feel the second version here allows me to bypass obtaining the type information "..Point" from the variable name when reading. Interestingly, I wonder how this type of method would be converted: addArcWithCenter(center: CGPoint, radius: CGFloat, startAngle: CGFloat, endAngle: CGFloat, clockwise: Bool) You'd perhaps think of addArcWith(center: CGPoint), but then you'd need to have 'center' in the variable name to convey meaning. Keeping addArcWithCenter maintains obj-c status quo. addArc(withCenter: CGPoint) is more Swifty, but you may have repetition if your variable is named centerPoint, or similar. I have a feeling it would be kept as is.
- equalarrow 11y ago
  There has been discussion on one of the Swift lists (forget which one off the top of my head) to require first param. So this is definitely a known and active (still) topic.

by TillE 11y ago

ChrisLTD 11y ago

I would screw up that first named argument thing every time if it weren't for Xcode's autocomplete.

ceeK 11y ago

To be honest, even as a fairly seasoned iOS developer I still prefer to have a non-optional first argument in my APIs. Whereas the post's example compares: path.addLineToPoint(CGPoint(x: 100, y: 0)) -- to -- path.addLineTo(CGPoint(x: 100, y: 0)) I've been doing it as so: path.addLine(toPoint: CGPoint(x: 100, y: 0)) ...requiring the "toPoint", which can swapped out true method overloading style: path.addLine(toArc:...) In your internal method implementation, Swift allows you to replace the external method name with an internal one, so that it's still nice to work with: func addLine(toPoint point: CGPoint) { ... } I personally think it's a lot more readable. Otherwise the first argument has to have a really descriptive class name (recommended for sure, but often not the case).

seivan 11y ago
Yup, that's what I would like. It's silly to remove the point from the method name and not makes it into a named argument that could be overloaded for others. I might just do that for my own stuff. I don't like the notion of the first argument not being in either the method name or as a named argument.
nardi 11y ago
The point here (no pun intended) is to stop repeating noun phrases at the call site. Your call site says "point" twice for no reason: path.addLine(toPoint: CGPoint(x: 100, y: 0)) See the "toPoint: CGPoint". It's useless repetition. The new form eliminates it: path.addLineTo(CGPoint(x: 100, y: 0)) It's clear you're adding a line to a point, because it says "Point" right there. Even if you have a variable for this point already, it works great: path.addLineTo(point) Or maybe this is a more specifically named point? path.addLineTo(centerPoint) It's clear from all that you're adding a line to a point. Swift has an emphasis on concise syntax, and removing the repetition, IMO, is a nice win in readability.
- ceeK 11y ago
  You do have a good point, and something I didn't explicitly notice before. This does seem to have the indirect consequence of enforcing some sort of type information in the variable name, but I expect many iOS developers do that regardless. It'd also be interesting to see the impact on readability when you have longer variable names. `point` definitely makes it more concise here. But if you had several points within the same scope, readability may suffer given type information is typically at the end of a variable name? path.addLineTo(childViewTopLeftPoint) path.addCurveTo(childViewTopRightPoint, withControlPoint1: arbitrary1Point, andControlPoint2: arbitrary2Point) path.addLine(toPoint: childViewTopLeftPoint) path.addCurve(toPoint: childViewTopRightPoint, withControlPoint1: arbitrary1Point, andControlPoint2: arbitrary2Point) I feel the second version here allows me to bypass obtaining the type information "..Point" from the variable name when reading. Interestingly, I wonder how this type of method would be converted: addArcWithCenter(center: CGPoint, radius: CGFloat, startAngle: CGFloat, endAngle: CGFloat, clockwise: Bool) You'd perhaps think of addArcWith(center: CGPoint), but then you'd need to have 'center' in the variable name to convey meaning. Keeping addArcWithCenter maintains obj-c status quo. addArc(withCenter: CGPoint) is more Swifty, but you may have repetition if your variable is named centerPoint, or similar. I have a feeling it would be kept as is.
equalarrow 11y ago
There has been discussion on one of the Swift lists (forget which one off the top of my head) to require first param. So this is definitely a known and active (still) topic.