4 ms·

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,

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]; to object.(selector1:item1, selector2:item2); although I'm still not sure about the love of commas

ricardobeat 11y 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.
- protomyth 11y ago
  I'm more concerned about multiple selectors and what a mess it becomes, and yes, I wish they'd change the syntax.
  - nicky0 11y ago
    Not that it really matters, but you have your terminology wrong, those aren't selectors. The selector is the whole thing, not the parts.
    - protomyth 11y ago
      ok, sorry - long ago habit - yes the entire selector:part2: is the actual selector.
  - sadawi 11y ago
    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. I wouldn't want to see, for example: collectionView.(dequeueReusableCellWithReuseIdentifier:identifier, forIndexPath: indexPath) because that obscures the primary purpose of the method, which is to dequeue a cell. To me, this is preferable: collectionView.dequeueReusableCell(reuseIdentifier: "ImageCell", îndexPath: indexPath) 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?
    - pjene 11y ago
      Objective-C has no object methods, just pure multiple-dispatch for a generic "select" operation? that's amazing.
      - pcwalton 11y ago
        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.)
        LeoNatan25 11y ago
        Swift has not abandoned this dispatch method "from the get-go", it is still very much one of the supported dispatch methods in the Swift runtime. https://news.ycombinator.com/item?id=10725707 https://news.ycombinator.com/item?id=10725707 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
        pcwalton 11y ago
        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.

ricardobeat 11y 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.

protomyth 11y ago
I'm more concerned about multiple selectors and what a mess it becomes, and yes, I wish they'd change the syntax.
- nicky0 11y ago
  Not that it really matters, but you have your terminology wrong, those aren't selectors. The selector is the whole thing, not the parts.
  - protomyth 11y ago
    ok, sorry - long ago habit - yes the entire selector:part2: is the actual selector.
- sadawi 11y ago
  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. I wouldn't want to see, for example: collectionView.(dequeueReusableCellWithReuseIdentifier:identifier, forIndexPath: indexPath) because that obscures the primary purpose of the method, which is to dequeue a cell. To me, this is preferable: collectionView.dequeueReusableCell(reuseIdentifier: "ImageCell", îndexPath: indexPath) 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?
  - pjene 11y ago
    Objective-C has no object methods, just pure multiple-dispatch for a generic "select" operation? that's amazing.
    - pcwalton 11y ago
      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.)
      - LeoNatan25 11y ago
        Swift has not abandoned this dispatch method "from the get-go", it is still very much one of the supported dispatch methods in the Swift runtime. https://news.ycombinator.com/item?id=10725707 https://news.ycombinator.com/item?id=10725707 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
        pcwalton 11y ago
        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.