It's Coming: The Great Swift API Transformation (opens in new tab)

(swift.org)

163 pointsceeK10y ago25 comments

25 comments

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.

ceeKOP10y 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).

nardi10y 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.

1 more reply

seivan10y 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.

equalarrow10y 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.

ChrisLTD10y ago

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

fleshweasel10y ago

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."

e28eta10y ago

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.

bjourne10y ago

If it is one that that should be known about Apple software by now, is that things will change from under your feet. :)

jeremy_wiebe10y ago

True, but given how young Swift is I'm happy they're not afraid to challenge how things work currently in order to make Swift better in the long run.

pjmlp10y ago

And yet only Microsoft gets criticised for doing it. :)

breakingcups10y ago

Microsoft is actually the king of backwards compatibility in my view, and anyone who claims otherwise should peruse Raymond Chen's blog.

Benjammer10y ago

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.

Something like this:

    class BezierPath: NSObject {
      func add(LineTo lineTo: CGPoint) {}
      func add(ArcWithCenter center: CGPoint, radius: CGFloat, 
                          startAngle: CGFloat, endAngle: CGFloat, 
                          clockwise: Bool) {}
      func add(CurveTo endPoint: CGPoint, controlPoint1 point1: CGPoint, 
                          controlPoint2 point2: CGPoint) {}
      func add(QuadCurveTo endPoint: CGPoint, controlPoint: CGPoint) {}
    }

    class main {
        func run() {
            let path = BezierPath()
            let point1 = CGPoint()
            let point2 = CGPoint()

            path.add(LineTo: CGPoint(x: 100, y: 0))
            path.add(ArcWithCenter: CGPointZero, radius: 20.0, 
                             startAngle: 0.0, endAngle: CGFloat(M_PI) * 2.0, 
                             clockwise: true)
            path.add(CurveTo: CGPoint(x: 100, y: 0), controlPoint1: point1, 
                             controlPoint2: point2)
            path.add(QuadCurveTo: point2, controlPoint: point1)
        }
    }

The difference is mostly that it looks even more concise when using code completion. You would see:

    path.add(LineTo: CGPoint)

Instead of:

    path.addLineTo(point: CGPoint)

nostrademons10y ago

It gets really annoying when you have short single-arg functions. Imagine what swap(_:_) or Collection.suffix(_) would look like with mandatory first arguments.

protomyth10y ago

I do wish the Swift developers had allowed actual Objective-C calls in Swift to make it look the same.

Objective-C

  [aPath addLineToPoint:CGPointMake(200.0, 40.0)];

proposed

  aPath.(addLineToPoint:CGPoint(200.0, 40.0));

the more complicated example would be:

Objective-C

  [object selector1:item1 selector2:item2];

  object.(selector1:item1, selector2:item2);

although I'm still not sure about the love of commas

ricardobeat10y ago

Why would that be better than this, which still 'looks the same'?

     aPath.addLineToPoint(CGPoint(200.0, 40.0))

I don't see how your proposal would fit with Swift's syntax.

protomyth10y ago

I'm more concerned about multiple selectors and what a mess it becomes, and yes, I wish they'd change the syntax.

2 more replies

j / k navigate · click thread line to collapse

25 comments

TillE10y ago

ceeKOP10y 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).

nardi10y 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.

1 more reply

seivan10y ago

equalarrow10y 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.

ChrisLTD10y ago

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

fleshweasel10y ago

e28eta10y ago

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.

bjourne10y ago

If it is one that that should be known about Apple software by now, is that things will change from under your feet. :)

jeremy_wiebe10y ago

True, but given how young Swift is I'm happy they're not afraid to challenge how things work currently in order to make Swift better in the long run.

pjmlp10y ago

And yet only Microsoft gets criticised for doing it. :)

breakingcups10y ago

Microsoft is actually the king of backwards compatibility in my view, and anyone who claims otherwise should peruse Raymond Chen's blog.

Benjammer10y ago

Something like this:

    class BezierPath: NSObject {
      func add(LineTo lineTo: CGPoint) {}
      func add(ArcWithCenter center: CGPoint, radius: CGFloat, 
                          startAngle: CGFloat, endAngle: CGFloat, 
                          clockwise: Bool) {}
      func add(CurveTo endPoint: CGPoint, controlPoint1 point1: CGPoint, 
                          controlPoint2 point2: CGPoint) {}
      func add(QuadCurveTo endPoint: CGPoint, controlPoint: CGPoint) {}
    }

    class main {
        func run() {
            let path = BezierPath()
            let point1 = CGPoint()
            let point2 = CGPoint()

            path.add(LineTo: CGPoint(x: 100, y: 0))
            path.add(ArcWithCenter: CGPointZero, radius: 20.0, 
                             startAngle: 0.0, endAngle: CGFloat(M_PI) * 2.0, 
                             clockwise: true)
            path.add(CurveTo: CGPoint(x: 100, y: 0), controlPoint1: point1, 
                             controlPoint2: point2)
            path.add(QuadCurveTo: point2, controlPoint: point1)
        }
    }

The difference is mostly that it looks even more concise when using code completion. You would see:

    path.add(LineTo: CGPoint)

Instead of:

    path.addLineTo(point: CGPoint)

nostrademons10y ago

It gets really annoying when you have short single-arg functions. Imagine what swap(_:_) or Collection.suffix(_) would look like with mandatory first arguments.

protomyth10y ago

I do wish the Swift developers had allowed actual Objective-C calls in Swift to make it look the same.

Objective-C

  [aPath addLineToPoint:CGPointMake(200.0, 40.0)];

proposed

  aPath.(addLineToPoint:CGPoint(200.0, 40.0));

the more complicated example would be:

Objective-C

  [object selector1:item1 selector2:item2];

  object.(selector1:item1, selector2:item2);

although I'm still not sure about the love of commas

ricardobeat10y ago

Why would that be better than this, which still 'looks the same'?

     aPath.addLineToPoint(CGPoint(200.0, 40.0))

I don't see how your proposal would fit with Swift's syntax.

protomyth10y ago

I'm more concerned about multiple selectors and what a mess it becomes, and yes, I wish they'd change the syntax.

2 more replies

j / k navigate · click thread line to collapse