What is up with names not being Strings any more in Swift 4?


(Manfred Schubert) #1

Why are names no longer Strings any more in Swift 4? I am all for type safety, but now things like

NSImage(named: "Icon.png")

become

NSImage(named: NSImage.Name(rawValue: "Icon.png"))

and

NSWindowController(windowNibName: "Window")

becomes

NSWindowController(windowNibName: NSNib.Name(rawValue: "Window").

What does this contrived way of wrapping a String into something else gain in me in safety in exchange for this longer and more difficult to read code? For me a "name" is a prime example of a String. If a name isn't one, then nothing is.

One place where this makes a lot of sense to have is binding, and there is now NSBindingName. But how do I create a binding name for a property in a way that the compiler can check for validity? I only see the constructor from rawValue (String), but if I only create the binding name from a String I gain nothing in security.

Kind regards,

Manfred


(Joe Groff) #2

Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:

extension NSImage.Name {
  static let myImage = Name("myImage")
}

-Joe

···

On Jul 17, 2017, at 8:26 AM, Jon Shier via swift-users <swift-users@swift.org> wrote:

  Like Notification.Name, I believe those types are supposed to help you namespace your string constants when you access them. I’d recommend using a code gen tool to generate them from your image assets, like:

extension NSImage.Name {
  static let customImage = NSImage.Name(rawValue: “customImage”)
}

Which can then be used like: NSImage(named: .customImage). That’s the ultimate use goal. It does make the old code awkward and a pain to migrate though.


(Jon Shier) #3

Like Notification.Name, I believe those types are supposed to help you namespace your string constants when you access them. I’d recommend using a code gen tool to generate them from your image assets, like:

extension NSImage.Name {
  static let customImage = NSImage.Name(rawValue: “customImage”)
}

Which can then be used like: NSImage(named: .customImage). That’s the ultimate use goal. It does make the old code awkward and a pain to migrate though.

Jon

···

On Jul 17, 2017, at 11:20 AM, Manfred Schubert via swift-users <swift-users@swift.org> wrote:

Why are names no longer Strings any more in Swift 4? I am all for type safety, but now things like

NSImage(named: "Icon.png")

become

NSImage(named: NSImage.Name(rawValue: "Icon.png"))

and

NSWindowController(windowNibName: "Window")

becomes

NSWindowController(windowNibName: NSNib.Name(rawValue: "Window").

What does this contrived way of wrapping a String into something else gain in me in safety in exchange for this longer and more difficult to read code? For me a "name" is a prime example of a String. If a name isn't one, then nothing is.

One place where this makes a lot of sense to have is binding, and there is now NSBindingName. But how do I create a binding name for a property in a way that the compiler can check for validity? I only see the constructor from rawValue (String), but if I only create the binding name from a String I gain nothing in security.

Kind regards,

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


(Manfred Schubert) #4

It would be possible to do the same thing as an extension to String without making the default/simple case more complicated. So I would have said this is overkill, but I'm fine with it.

What remains is the question whether it is possible to create NSBindingNames in a safe way, like from #selector().

Kind regards,

Manfred

···

Am 17.07.2017 um 17:47 schrieb Joe Groff <jgroff@apple.com>:

Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:

extension NSImage.Name {
static let myImage = Name("myImage")
}


(Joe Groff) #5

Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:

extension NSImage.Name {
static let myImage = Name("myImage")
}

It would be possible to do the same thing as an extension to String without making the default/simple case more complicated. So I would have said this is overkill, but I'm fine with it.

By making it a separate type, though, it lets you define constants without polluting String's namespace, and lets the type system prevent typos or accidental misuse of a name.

What remains is the question whether it is possible to create NSBindingNames in a safe way, like from #selector().

If you want to ensure that the string value corresponds to a declaration, maybe you could use #keyPath, which ought to be interchangeable with a string literal but checked by the compiler.

-Joe

···

On Jul 17, 2017, at 9:04 AM, Manfred Schubert <dev@schubert-it.com> wrote:

Am 17.07.2017 um 17:47 schrieb Joe Groff <jgroff@apple.com>:


(Jon Shier) #6

Making them an extension on String makes them visible everywhere String is used, unless you limit the visibility in some way, which impacts the performance of autocomplete and fills it with random constants. Like I said, part of the reason for this is to separate the constants.

Jon

···

On Jul 17, 2017, at 12:04 PM, Manfred Schubert <dev@schubert-it.com> wrote:

Am 17.07.2017 um 17:47 schrieb Joe Groff <jgroff@apple.com>:

Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:

extension NSImage.Name {
static let myImage = Name("myImage")
}

It would be possible to do the same thing as an extension to String without making the default/simple case more complicated. So I would have said this is overkill, but I'm fine with it.

What remains is the question whether it is possible to create NSBindingNames in a safe way, like from #selector().

Kind regards,

Manfred


(Manfred Schubert) #7

I see. Thanks for clarifying.

Manfred

···

Am 17.07.2017 um 18:08 schrieb Jon Shier <jon@jonshier.com>:

Making them an extension on String makes them visible everywhere String is used, unless you limit the visibility in some way, which impacts the performance of autocomplete and fills it with random constants.


(Manfred Schubert) #8

Excellent. Thanks a lot!

Manfred

···

Am 17.07.2017 um 18:12 schrieb Joe Groff <jgroff@apple.com>:

If you want to ensure that the string value corresponds to a declaration, maybe you could use #keyPath, which ought to be interchangeable with a string literal but checked by the compiler.


#9

Could / should these types be ExpressibleByStringLiteral?

Nevin

···

On Mon, Jul 17, 2017 at 12:47 PM, Manfred Schubert via swift-users < swift-users@swift.org> wrote:

> Am 17.07.2017 um 18:08 schrieb Jon Shier <jon@jonshier.com>:
>
> Making them an extension on String makes them visible everywhere String
is used, unless you limit the visibility in some way, which impacts the
performance of autocomplete and fills it with random constants.

I see. Thanks for clarifying.

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


(Greg Parker) #10

They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.

···

On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:

Could / should these types be ExpressibleByStringLiteral?

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler


(Manfred Schubert) #11

The thing is, with Notification.Name, you have to use them at least twice. So everybody is creating a constant. And typos in the String that defines the constant don't matter. So this solves the problem. With NSNib however, the default case is to use the name only once. And I would say with NSImage it's probably the same. I don't think people have been defining constants for these when they are only used once. It makes the code unnecessarily longer and more complicated. And a typo in the String that defines the constant matter just as much as a typo in the String literal. So in the default case this doesn't solve a problem.

Kind regards,

Manfred

···

Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users <swift-users@swift.org>:

On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:

Could / should these types be ExpressibleByStringLiteral?

They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.


(Hooman Mehr) #12

I think this should be a feature of Xcode to automatically generate / maintain these constants: When you add assets or create interface builder files, a plug-in could take care of generating / updating such constants and you would get auto-complete and type safety for free.

···

On Jul 18, 2017, at 3:56 AM, Manfred Schubert via swift-users <swift-users@swift.org> wrote:

Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users <swift-users@swift.org>:

On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:

Could / should these types be ExpressibleByStringLiteral?

They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.

The thing is, with Notification.Name, you have to use them at least twice. So everybody is creating a constant. And typos in the String that defines the constant don't matter. So this solves the problem. With NSNib however, the default case is to use the name only once. And I would say with NSImage it's probably the same. I don't think people have been defining constants for these when they are only used once. It makes the code unnecessarily longer and more complicated. And a typo in the String that defines the constant matter just as much as a typo in the String literal. So in the default case this doesn't solve a problem.

Kind regards,

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


(Jon Shier) #13

I'd agree with that. Fortunately there are tools out there that can parse such things and generate the constants for us already. Waiting for Xcode to implement such common sense quality of life improvements probably won't end. I'll file bugs in the meantime though.

Jon

···

On Jul 18, 2017, at 1:38 PM, Hooman Mehr via swift-users <swift-users@swift.org> wrote:

I think this should be a feature of Xcode to automatically generate / maintain these constants: When you add assets or create interface builder files, a plug-in could take care of generating / updating such constants and you would get auto-complete and type safety for free.

On Jul 18, 2017, at 3:56 AM, Manfred Schubert via swift-users <swift-users@swift.org> wrote:

Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users <swift-users@swift.org>:

On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:

Could / should these types be ExpressibleByStringLiteral?

They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.

The thing is, with Notification.Name, you have to use them at least twice. So everybody is creating a constant. And typos in the String that defines the constant don't matter. So this solves the problem. With NSNib however, the default case is to use the name only once. And I would say with NSImage it's probably the same. I don't think people have been defining constants for these when they are only used once. It makes the code unnecessarily longer and more complicated. And a typo in the String that defines the constant matter just as much as a typo in the String literal. So in the default case this doesn't solve a problem.

Kind regards,

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

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