Notification.Name


(Brent Royal-Gordon) #1

Not 100% sure this belongs here, but I'll bite.

The new `Notification.Name` type is a beautiful application of SE-0033 "Import Objective-C Constants as Swift Types"[1] which removes a lot of boilerplate. However, I think it puts the resulting constants in the wrong place. They all get piled into `Notification.Name`, resulting in:

  Notification.Name.NSSystemTimeZoneDidChange
  Notification.Name.NSThreadWillExit
  Notification.Name.NSURLCredentialStorageChanged
  Notification.Name.NSUbiquityIdentityDidChange
  Notification.Name.NSUndoManagerCheckpoint

I think these would be a lot better off as:

  TimeZone.systemTimeZoneDidChange
  Thread.willExit
  URLCredentialStorage.changed
  FileManager.ubiquityIdentityDidChange
  UndoManager.checkpoint

Most of these could probably be inferred by prefix matching, but some, like `TimeZone.systemTimeZoneDidChange` and `FileManager.ubiquityIdentityDidChange`, would probably have to be done manually. There might even be a few which have no natural attachment point, though I can't think of any off the top of my head.

To be clear, I don't think we want this behavior on all `swift_wrapper` types. For instance, the specified behavior is probably appropriate for `HKQuantityTypeIdentifier` and `NSErrorDomain`, the primary examples in SE-0033. But `Notification.Name` is a slightly different use from what we imagined for this feature, and I think it needs a slightly different behavior.

So, what's the best way to pursue fixing this issue?

1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?

2. An amendment to SE-0033?

3. A radar filed with the Foundation team?

4. A blizzard of radars filed with *every* framework team?

5. Deferral to post-Swift 3?

[1] https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

···

--
Brent Royal-Gordon
Architechies


(Ben Rimmington) #2

[Cc: Michael Ilseman]

Not 100% sure this belongs here, but I'll bite.

The new `Notification.Name` type is a beautiful application of SE-0033 "Import Objective-C Constants as Swift Types"[1] which removes a lot of boilerplate. However, I think it puts the resulting constants in the wrong place. They all get piled into `Notification.Name`, resulting in:

  Notification.Name.NSSystemTimeZoneDidChange
  Notification.Name.NSThreadWillExit
  Notification.Name.NSURLCredentialStorageChanged
  Notification.Name.NSUbiquityIdentityDidChange
  Notification.Name.NSUndoManagerCheckpoint

I think these would be a lot better off as:

  TimeZone.systemTimeZoneDidChange
  Thread.willExit
  URLCredentialStorage.changed
  FileManager.ubiquityIdentityDidChange
  UndoManager.checkpoint

Most of these could probably be inferred by prefix matching, but some, like `TimeZone.systemTimeZoneDidChange` and `FileManager.ubiquityIdentityDidChange`, would probably have to be done manually. There might even be a few which have no natural attachment point, though I can't think of any off the top of my head.

Is this another case where SE-0033 and SE-0044 can work together?
<http://article.gmane.org/gmane.comp.lang.swift.evolution/19946>

For example, in <Foundation/NSTimeZone.h> by adding the `swift_name` attribute:

  FOUNDATION_EXPORT NSNotificationName const NSSystemTimeZoneDidChangeNotification
  NS_SWIFT_NAME(TimeZone.systemTimeZoneDidChange);

The constant should hopefully be imported into Swift as:

  extension TimeZone {
      public static let systemTimeZoneDidChange: NSNotification.Name
  }

-- Ben

···

On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

To be clear, I don't think we want this behavior on all `swift_wrapper` types. For instance, the specified behavior is probably appropriate for `HKQuantityTypeIdentifier` and `NSErrorDomain`, the primary examples in SE-0033. But `Notification.Name` is a slightly different use from what we imagined for this feature, and I think it needs a slightly different behavior.

So, what's the best way to pursue fixing this issue?

1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?

2. An amendment to SE-0033?

3. A radar filed with the Foundation team?

4. A blizzard of radars filed with *every* framework team?

5. Deferral to post-Swift 3?

[1] https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

--
Brent Royal-Gordon
Architechies


(Tony Parker) #3

Hi Brent,

In general, I agree with your idea that the scope of the name of these things is with the type it’s used for. The type of it is of course Notification.Name.

One thing we did in the short term to make this feature even remotely possible was to add an importer rule: global const NSStrings that end in ‘Notification’ are imported as Notification.Name.something — otherwise everyone would have to either cast these, or we’d have to audit the whole SDK to add an attribute to each one.

I think we can probably do a better job of putting these where they belong with a combination of setting the attribute and using either API notes or the NS_SWIFT_NAME macro to get them into the right scope. Probably the only real way to accomplish this is to file radars on each relevant framework (including Foundation itself).

Thanks,
- Tony

···

On Jun 29, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Not 100% sure this belongs here, but I'll bite.

The new `Notification.Name` type is a beautiful application of SE-0033 "Import Objective-C Constants as Swift Types"[1] which removes a lot of boilerplate. However, I think it puts the resulting constants in the wrong place. They all get piled into `Notification.Name`, resulting in:

  Notification.Name.NSSystemTimeZoneDidChange
  Notification.Name.NSThreadWillExit
  Notification.Name.NSURLCredentialStorageChanged
  Notification.Name.NSUbiquityIdentityDidChange
  Notification.Name.NSUndoManagerCheckpoint

I think these would be a lot better off as:

  TimeZone.systemTimeZoneDidChange
  Thread.willExit
  URLCredentialStorage.changed
  FileManager.ubiquityIdentityDidChange
  UndoManager.checkpoint

Most of these could probably be inferred by prefix matching, but some, like `TimeZone.systemTimeZoneDidChange` and `FileManager.ubiquityIdentityDidChange`, would probably have to be done manually. There might even be a few which have no natural attachment point, though I can't think of any off the top of my head.

To be clear, I don't think we want this behavior on all `swift_wrapper` types. For instance, the specified behavior is probably appropriate for `HKQuantityTypeIdentifier` and `NSErrorDomain`, the primary examples in SE-0033. But `Notification.Name` is a slightly different use from what we imagined for this feature, and I think it needs a slightly different behavior.

So, what's the best way to pursue fixing this issue?

1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?

2. An amendment to SE-0033?

3. A radar filed with the Foundation team?

4. A blizzard of radars filed with *every* framework team?

5. Deferral to post-Swift 3?

[1] https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Michael Ilseman) #4

[Cc: Michael Ilseman]

Not 100% sure this belongs here, but I'll bite.

The new `Notification.Name` type is a beautiful application of SE-0033 "Import Objective-C Constants as Swift Types"[1] which removes a lot of boilerplate. However, I think it puts the resulting constants in the wrong place. They all get piled into `Notification.Name`, resulting in:

  Notification.Name.NSSystemTimeZoneDidChange
  Notification.Name.NSThreadWillExit
  Notification.Name.NSURLCredentialStorageChanged
  Notification.Name.NSUbiquityIdentityDidChange
  Notification.Name.NSUndoManagerCheckpoint

I think these would be a lot better off as:

  TimeZone.systemTimeZoneDidChange
  Thread.willExit
  URLCredentialStorage.changed
  FileManager.ubiquityIdentityDidChange
  UndoManager.checkpoint

Most of these could probably be inferred by prefix matching, but some, like `TimeZone.systemTimeZoneDidChange` and `FileManager.ubiquityIdentityDidChange`, would probably have to be done manually. There might even be a few which have no natural attachment point, though I can't think of any off the top of my head.

Is this another case where SE-0033 and SE-0044 can work together?
<http://article.gmane.org/gmane.comp.lang.swift.evolution/19946>

For example, in <Foundation/NSTimeZone.h> by adding the `swift_name` attribute:

  FOUNDATION_EXPORT NSNotificationName const NSSystemTimeZoneDidChangeNotification
  NS_SWIFT_NAME(TimeZone.systemTimeZoneDidChange);

The constant should hopefully be imported into Swift as:

  extension TimeZone {
      public static let systemTimeZoneDidChange: NSNotification.Name
  }

That is certainly in the spirit of SE-0044, and anything that is “typified” from SE-0033 is valid host for import-as-member. There are a few bugs in that interaction that I’m currently working out (e.g. with opaque pointers), but I think it’s reasonable to allow users of swift_name to choose a host that is different from NSNotification. If your example doesn’t work, please file a JIRA.

···

On Jun 30, 2016, at 9:10 AM, Ben Rimmington <me@benrimmington.com> wrote:

On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

-- Ben

To be clear, I don't think we want this behavior on all `swift_wrapper` types. For instance, the specified behavior is probably appropriate for `HKQuantityTypeIdentifier` and `NSErrorDomain`, the primary examples in SE-0033. But `Notification.Name` is a slightly different use from what we imagined for this feature, and I think it needs a slightly different behavior.

So, what's the best way to pursue fixing this issue?

1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?

2. An amendment to SE-0033?

3. A radar filed with the Foundation team?

4. A blizzard of radars filed with *every* framework team?

5. Deferral to post-Swift 3?

[1] https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

--
Brent Royal-Gordon
Architechies