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.
...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).
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.
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?
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.
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.
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.
The title they chose implies that they're actually changing the APIs to take full advantage of Swift language features. Perhaps they should have named the article "We're renaming some classes and methods."
They're actually changing the way Obj-C APIs are "imported" into Swift. This doesn't rename the method calls, it does more invasive name changes as part of the bridging.
So the class UIBezierPath and it's method addLineToPoint: haven't changed, and are still written in Obj-C. The difference is in how they're called from Swift code.
Presumably it'll operate the same way in reverse, and this isn't specific to Apple frameworks/classes.
Could they just go all the way and use a mandatory first argument name to make things even more concise? That would get away from something that annoys a lot of people about Swift, the implicitly unnamed first arguments.
It gets really annoying when you have short single-arg functions. Imagine what swap(_:_) or Collection.suffix(_) would look like with mandatory first arguments.
To me, something like your syntax makes sense when there isn't a clear hierarchy among selectorPart1, selectorPart2, selectorPart3, etc. However, in every case where a method can be thought of as having a single primary action that is refined by arguments, I believe the action(argument1:value1, argument2:value2) syntax makes more sense.
The long first component of the Objective C selector ("dequeueReusableCellWithReuseIdentifier") is just an artifact of ObjC's lack of distinction between method names and parameter names, which forces the API creator to use words like "With" to accomplish what Swift can do natively.
What are some examples of methods you think make more sense with your syntax?
Objective-C does have object methods, but they're dynamically typed: methods can come and go at runtime, method names can be constructed from strings, and there's no need to downcast an object of a superclass type to the subclass type before calling a method on that subclass. This design choice basically forces Objective-C into doing a hash table lookup and indirect dispatch for all method calls as a base case. This logic is encapsulated in the "objc_msgSend" function, which the compiler compiles all method invocations into a call to.
(If you're thinking "wow, that must be slow", you're right: objc_msgSend is very heavily optimized, but you can't beat one load from a fixed offset and an indirect jump as in C++ and Java. This is why Swift made the decision to abandon this model from the get-go. Other dynamic languages have ways to optimize this and eliminate the hash table lookup in most cases, but these techniques require self-modifying code, which Apple doesn't want to use; the only feasible solution for Apple's native language was to switch to a different semantics.)
Well, for Objective-C compatibility, and maybe for interfaces/protocols (depending on whether they use fat pointers or not), they need that capability. But Swift tries to push you into C++-like vtables when possible.
