[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift

[Dave Abrahams]

Thanks for your review, Jacob—

on Sat Jan 23 2016, Jacob Bandes-Storch <swift-evolution at swift.org> wrote:

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md
>
>> What is your evaluation of the proposal?
>
> I would really appreciate seeing what *all* of the Foundation/Cocoa/Cocoa
> Touch APIs would look like when imported using this scheme. If we're going
> to bikeshed API translation, we should bikeshed all of it to avoid
> inconsistency. (It may be that some issues aren't resolvable with the
> simple rules proposed, and instead we should improve the API overlays.)
>
> Some specific concerns:
>
>      func *reversing()* -> UIBezierPath
>
> I believe this would be better named *reversed()*.

It certainly would.  I wonder if it's possible for us to tune the
heuristics accordingly, and how many other places that might fix.  My
research tells me this is a one-off problem that probably should be
handled “on a per-API basis via annotation within the Objective-C
headers”
(c.f. https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md#proposed-solution)

  $ git grep -nHE -e 'func [a-z]*ing\>\(\)' | grep -v 'string()'
  ../../Platforms/OSX/DiscRecording.swift:678:  func encoding() -> UInt
  ../../Platforms/OSX/Quartz.swift:1822:  func mirroring() -> Bool
  ../../Platforms/OSX/SceneKit.swift:4762:  class func spring() -> SCNPhysicsField
  ../../Platforms/OSX/WebKit.swift:340:  func padding() -> String!
  ../../Platforms/iOS/SceneKit.swift:4474:  class func spring() -> SCNPhysicsField
  ../../Platforms/iOS/UIKit.swift:2237:  func reversing() -> UIBezierPath
  ../../Platforms/tvOS/SceneKit.swift:4474:  class func spring() -> SCNPhysicsField
  ../../Platforms/tvOS/UIKit.swift:1723:  func reversing() -> UIBezierPath
  ../../Platforms/watchOS/UIKit.swift:424:  func reversing() -> UIBezierPath

Except for reversing, these are all fine AFAICT.

>     var *dateComponentUndefined*: Int { get }
>
> It seems pretty weird to have a global/top-level constant that starts with
> a lowercase letter, 

I get that.  Starting with lowercase is in conformance with the
guidelines as written, FWIW.

> and whose first 2 subwords are describing its type.

That's compensating for weak type information.

>     class func *darkGray*() -> UIColor
>
> I would rather see this imported as `class var *DarkGray*: UIColor { get }`.

Why should we capitalize some vars and not others?

> Otherwise, I'm okay with the proposed changes. I really like the "Add
> Default Arguments" section. :-)
>
>> Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> Yes. The (current) majority of Swift users are writing software for Apple
> platforms, so they interact constantly with Obj-C APIs such as these.
>
>> How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> Fairly in-depth.
>
> Jacob
>
> On Fri, Jan 22, 2016 at 1:02 PM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of SE-0005"Better Translation of Objective-C APIs Into Swift"
>> begins now and runs through January 31, 2016. The proposal is available
>> here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
>> review manager. When replying, please try to keep the proposal link at the
>> top of the message:
>>
>> Proposal link:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md
>>
>> Reply text
>>
>> Other replies
>>
>> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What
>> goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift. When writing your review, here are some questions you might want to
>> answer in your review:
>>
>>    - What is your evaluation of the proposal?
>>    - Is the problem being addressed significant enough to warrant a
>>    change to Swift?
>>    - Does this proposal fit well with the feel and direction of Swift?
>>    - If you have used other languages or libraries with a similar
>>    feature, how do you feel that this proposal compares to those?
>>    - How much effort did you put into your review? A glance, a quick
>>    reading, or an in-depth study?
>>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Doug Gregor
>>
>> Review Manager
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave