4 ms·
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:
by 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 agoYup, 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 agoThe 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 agoYou 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 agoThere 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.